A great start to the New Year

Happy New Year! FlingOS had a fantastic year in 2015 and 2016 promises to be another exciting year of big progress. Here’s some of the highlights from 2015 and our plans for 2016.

Happy New Year! FlingOS had a fantastic year in 2015 and 2016 promises to be another exciting year of big progress. Already in the first 24-hours of 2016 we’ve had over 12,000 views of our website (and that’s before we count the blog, community forums, codebase and YouTube videos!) Here’s some of the highlights from 2015 and our plans for 2016.

Our first summer intern, Roland Baranyi, joined us to add MIPS support to our compiler and created our FlingOops testing kernel. Sponsored by Imagination Technologies, Roland helped reform the Drivers Compiler into a cross-platform compiler and added the MIPS target architecture library. We also created a basic test kernel for the Creator CI20. More on where this is headed in 2016 further down!

On September 17th we launched a new FlingOS – a total new look for our website and a lot of content and progress to back it up. We added over 30 new articles and published our 10-video Getting Started tutorial series on YouTube. Since launch we’ve had thousands of views per month of the articles and just over a thousand per month of our videos.

On top of all that, I’ve been presenting about FlingOS and the educational problems the project is solving, in and around Bristol. I’ll be giving another talk in Hereford in February 2016. I also ran a series of lectures and workshops in the University of Bristol which were a resounding success.

In 2016 we’re aiming to build on our progress but also to better align what we’re producing with what industry wants and education needs. To achieve this, we’ll be creating an OS dev starter kit, aimed at A-Level and first-year university students.

The kit will be based on a embedded device to align with what new OS dev industry is aimed at (and which we hope Imagination will support us with using the Creator CI20 or their latest CI40 board). We will be creating a complete self-teach course and lecture course (with slides, notes, examples and exercises) and selling the complete kit at low cost. But as always, our main codebase a core articles will remain free and open-source.

To succeed in producing all this, FlingOS needs sponsorship (or investment) to hire 3 to 5 interns next summer (myself included!) and to cover our basic costs. We’re still looking for sponsors, investors or people to donate! Please head to our Sponsor page to find out more if you think you can help.

2016 promises to be a year of big progress, with lots of new articles, a solid codebase and more great tutorial videos. We hope you’ll join us on our journey and support us by sharing, liking and Tweeting (@Fling_OS).

Many thanks to everyone who helped make 2015 a solid milestone in the project’s development!

Following up: “Avoiding the UK IoT Disaster” (BrisTech, 2015-12-03)

I thought I’d take the time to write a short blog post following up on my presentation that I gave to BrisTech the other night (2015-02-03) titled “Avoiding the UK IoT Disaster”. In the talk, I highlighted not security or technical problems with IoT but a key educational problem that will be putting our industry at serious risk: Low-level development is not being taught in schools and is barely taught at Universities. Slides are available here.

During the presentation I highlighted a couple of possible problem-applications, where IoT devices are being programmed using high-level code (often Python) on top of an embedded Linux stacks. Such stacks and programming in Python allows rapid development and ease-of-update in future (which is useful/key for security) but sacrifices hardware efficiency and, even more so, battery life.

The specific example that I brought up was an IoT thermometer programmed in Python with wireless connectivity. I stated during the presentation that such a setup was not a good idea because thermometers were relatively simple devices that didn’t require such a complex stack and also that, as a device installed in a home, you would want a decent battery life.

This example caused some controversy and was the subject of a lot of the discussion at the end of the talk. One member of the audience, who works in the IoT industry, gave an interesting piece of analysis which is where I would like to start. His key point I feel worth highlighting is that, in his work, he sees three types of IoT device:

  1. Long-term, hard-to-replace devices, such as tremor and stress sensors built into bridges which often can’t be replaced, need to be extremely reliable and last a very, very long time (relative to standard technology cycles).
  2. Long-term, easy-to-replace devices, such as the thermometer example I gave earlier. These are devices which the user may want to have for a long time but they are easily replaceable.
  3. Short-term devices, where short-term is roughly the length of a standard technology cycle, 18 months to 2 years. These are devices which we would only expect to last that length of time before they need replacing.

The design approach for type (1) devices is relatively straightforward to analyse. These are devices which we may never be able to replace and which need to last a long time thus battery life is a top priority. So is reliability and security, which is easier to assure when there is less hardware and less software to test. Minimising the amount of hardware and minimising the amount of software executing for any length of time is key to increasing battery life. This is only possible using low-level software where modules can be stripped to a minimum and Python certainly doesn’t come under the heading of “low-power”.

The design approach for type (3) is arguably equally simple because the developers are likely to need the device to come quickly to market and to rapidly develop the next version and the version after that. This means Python and embedded Linux, which has regular security updates, and keep be developed and reasonably tested pretty quickly, makes sense.

The design approach for type (2) is what caused the most debate. Arguably, it is better for the user if the battery life is longer since, for a long-term device, it will be cheaper to not have to replace the battery or entire device so often. However, since the device can easily be replaced, it will probably not be an expensive, critical device with high per-unit margins (or at least, replacing the battery will be cheap so in the long-term, the per-unit profit is massively affected by the initial and maintained development cost). So using entirely low-level favours battery life but increases development cost. Using high-level significantly reduces development cost but also battery life and (possibly) user satisfaction. Which side of the line you go for probably depends on the specific device. Popular opinion at the talk was that Python for a thermometer was reasonable and on reflection I am inclined to agree.

In conversation after the event, Adam B. from Simpleweb showed me an unusual (but very cool) little device called an iBeacon. For those unfamiliar with iBeacons, they are small, thumb-sized low-energy Bluetooth devices which you can track the location of. This allows tracking people as they move through a shop or similar areas. The devices shown to me were sealed units, extremely small (so no space for big memory chips and processors nor heat dissipation) and without a replaceable battery. But per-unit they are pretty expensive and typical use cases require longevity. Thus software for such a device is likely to need to be entirely low-level, for battery life, despite the fact that the devices themselves are easily replaceable. This is an example of a type (2) device better suited to C-based dev than Python-based dev.

This example brought us to think about the development process for the devices. Adam, Roger Shepherd, a few others and I discussed the following areas which we agreed make sense as ideas but need significant work to improve or integrate with standard IoT development practices:

  1. As an example, using a Creator CI40 for rapid development (in Python or otherwise), experimenting with features, nailing down an exact design and then creating the final product in proper low-level code (if necessary). In an ideal world, it would be an easy, automated process to go from Python to pure low-level so that any device can be developed for best battery life. As it stands at the moment, this isn’t possible, which brings me on to points 2 and 3.
  2. GCC and similar C compilers are a nightmare to set up. Which makes development with them flaky and hard to do, all of which contributes to extended development time.
  3. Also, the C language and C libraries have poor modularisation in most code bases and there is a distinct lack of open-source, free systems for C-based package management. Thus, dedicated IoT software is either written from scratch every time or bought (at great expense) from another company (but often the bought libraries aren’t stripped down to just what is required). Thus low-level development for IoT (in C) is currently very expensive whereas in Python, there is great package management and modularisation.

Furthermore, as highlighted in my talk, C development is only going to get more expensive, as knowledge and understanding of low-level development by graudates entering the IoT industry decreases and the onus falls on companies to train new developers.

In conclusion then, while the example I gave during the talk was not the strongest technical example, there is still a strong case for teaching low-level development in schools and universities (though not to the exclusion of everything else). Furthermore, if  as an industry we could perfect a technique for high-level prototype development with easy transition to production low-level code, that’d be great. It would cut development costs, improve products (and reduce hardware costs). In the meantime, we will have to rely on team leaders to make an informed per-device choice of the tools and language used.