 I've posted a URL for the slides I was intending to publish. Then I remembered that, back in 2012... ...I discovered a bug in the wireless stack for free VSD. It turns out that I've completely forgotten about it... ...I'm still kind of bitten by it today. The URL is there, but I haven't managed to publish the slides yet. Excuse me. I don't know if you saw, I think it was yesterday, there was an IoT company that was making a juicer that announced that they were kind of closing up. There was a kind of a meme that started yesterday, but maybe it's to skewer a reference. I'm not really a hardware person, I like playing with hardware, but my background is open source software. I work with various open source projects from dealing with operating systems, from building the software or documenting it. I thought that it might be a good idea to run a workshop about this. This basically goes back, I realised actually back to Oshkamp 2012, all the way up to earlier this year. Oshkamp 2012 we actually had two talks, one from Melanie who was talking about dealing with ARM and building systems using Linux. I was kind of really outraged by the complications of the process, and I spent most of the day sitting over there trying to cross-compile my own free BSD image for Raspberry Pi, which I managed to do by the end of the day, and then the following day I ran a workshop on dealing with GPIO and how to get started. I've kind of completely long forgotten about this until last night when I looked at the slides, sorry not the slides, the website, and I realised that actually this thing did happen back then. Another event which had a kind of an impact on me was a chip hack back in 2013, which was just exposure to kind of closed tool chains which are forced on you and how brittle they can be and how you can just lose so much time trying to fight something that's put together quite badly. So back at Oshkamp number 46, Andrew asked me to give a presentation about the different operating systems in the BSD family and how they would be a benefit to someone. And I kind of did this all-encompassing talk about three or four different operating systems. And then Andrew asked me again to perhaps run a workshop, and for the workshop I've never done this before, and I thought it might be a bit much trying to cover three or four operating systems for a group of people and just focused on one being an FBSD. So the main reason that I thought I wasn't trying to kind of recruit new users but just to kind of plant seeds about what people could expect from an environment because a lot of projects are quite badly put together and especially in FBSD the tooling is quite nice that it could save you a lot of time. And because people are quite passionate about the project, the focus on technical correctness means that there's not that much, I mean there's bad code, but there's not kind of shortcuts everywhere and people pay attention to detail and that kind of feeds back in terms of respect for the user's time. So I was hoping to kind of demonstrate that to people. So in FBSD the ability to cross-compile is quite fundamental to the project. So you have these things not even for the operating system but you know like kind of bootloaders for Windows, you actually dynamically generate the visual studio configuration file using common Unix tools. And I didn't realise actually how bad things can be. So in this case like embedded visual studio you have this kind of GUI interface for setting up your software, you know where your dialogue boxes are going to go. Even the slightest movement of one of these dialogue boxes just renders your file completely corrupt and you have to kind of go back and start again. There's a gentleman by the name of Brett Victor who gave a talk called Inventing on Principle which was a few years old now but he talks about if you can reduce the feedback time between when you're experimenting with things, how that opens you up to kind of being able to explore new possibilities with these. So at the time this wasn't public but he was demonstrating a feature that's in Xcode as standard now which is dynamically as you're writing code the compiler in the background is experimenting with compiling your code so your mistakes are pointed out as you're actually introducing them rather than having this kind of long feedback time. And on the other extreme of it there's a talk from Usenix by Brian Cantrell which talks about before they had a detrace in Solaris where Sun had a very expensive computer by the name of the E-10000 and the average boot time for this machine was about 45 minutes and he was dealing with a customer where they misconfigured a system to be a router and they were doing SAP benchmarks and every so often it would stop processing the SAP benchmarks and start processing packets and then it would crash and then that was like 45 minutes again and so being able to kind of see that very quickly and flag it up is really beneficial for the operator. And so sometimes people don't find a solution and they kind of harbour or they suffer these environments people who fear restarting Windows because you're going to go through at least three reboot cycles and you're going to be down for about 30 to 45 minutes or you don't know what's going to be introduced when the system comes back up whether your machine is going to be actually operating still in the same way. And that kind of has other subtle issues as well where you're kind of fearful of being able to kind of test something out. A common issue is like in networking world where you're being sold in appliance and redundancy may not be an actual functionality that's available out of the box that's a licensed feature so which means once that thing is kind of live you're really fearful of making any changes and that's really sad because just because you put something out there doesn't mean that you got it right the first time for you to be in fear of making any further changes seems cruel. So I started thinking about for the workshop about what could I present my assumption is that you're all interested in hardware so how could I present this software project that would be appealing for someone who actually doesn't care about the software and just needs something to run on their hardware. And so this idea about saving time and the tooling that lets you kind of do things very quickly without having to do a whole bunch of reading up was on my mind. So some of the things that I decided to cover was the system is really well documented and the documentation is freely available and that's actually a part of the development project the development process for the project so you're not actually going around on a wild rampage trying to find a solution to the problem the implementation has the documentation with it. Cross compilation like I said is there out of the box and it's really easy single command and you're building your tool chain and you're building your operating system. In most of these cases there's a lot of expectation for knowledge about programming or system details but in the case of NetBSD there's a... the Lua language is embedded within the system so you have this kind of very high level interface 2D operating system so you can interact with it without having to know say C or C++. And then in an embed environment you usually have a slow board or you don't have much memory and your development time is quite slow so you can move away from that and actually develop on a desktop where you can build quickly and then make changes to production afterwards with a frump. Obviously security is a hot issue so a bit of tamper resistance with a subsystem that's built in so if there's any problems with a binary the system won't execute it for you which means that if you're writing badly written code which the system gets compromised you only get one shot at it once the binary changes the system won't run it for you. So in theory yes all of this stuff is there out of the box but the reality of it is is when you actually sit down with a group of people and try to work through your steps you actually realise the problems that are actually there that you assumed it was all perfect, right? On the previous slide. So in our case lots of the software relies on Otoconf. In this case if you take a modern operating system like Windows 10 Otoconf some of the stuff doesn't know about Windows 10 or even that there's a 64 bit version of Windows so that kind of blows up. It turned out that the images that we have for the things like the Beaglebone weren't actually bootable because we weren't marking partitions as bootable and it wasn't working. Various drivers weren't actually working either and there was actually differences in configuration so with someone with a Raspberry Pi there would have one result but someone with a Beaglebone would have a completely different result and for U-boot you can have different start-up scripts and they actually work in order and the firmware will try different boot scripts and depending on which board you have you have different scripts you kind of trip yourself up quite quickly because there's a mishmash of and not everything is in a single place. So those things were kind of fixed apart from the U-boot script which I'll come up to. The stuff that we managed to introduce into the operating system we managed to add more bits to Lua so you can do a lot more without actually having to know anything about the system details so things like adding users and things like that and moving out from the operating system we now actually also package up U-boot as well so you can take Windows or your Mac OS and within a couple of commands have generated firmware images for your board, be it a Raspberry Pi or a Beaglebone or things like that. Still to do improve the documentation I think trying to actually remove any background context and reduce it down so it's much more easier to get started. Some of the examples that I actually used were a bit too system-oriented and that also could be improved. We're planning to extend the Lua subsystem even more so you can do even more without actually having to write a single line of C or know anything about the system internals again. One of the problems that we have is like with Debian you have a hard-coded user by default and that creates a security problem because most people end up just pushing these images into public-facing devices and get caught out. So we were thinking of actually creating a mechanism where you would just create a file and put the user details in that and when the system boots up it would create that user for you but haven't actually worked out a way of doing that cleanly whether that's a one-time thing or if it's always going to be active so every time it boots up it will always perform this task. Also the organisation of the U-boot scripts it seems that though you have this kind of generic firmware environment the scripting for it is a bit of a mess because like I said the file can be named in different ways and depending on which file it is it will get picked first or it would be picked in a different order. That's all I have. So I ran this workshop at Oshoog and then also at B-sides in London and also in Cambridge as well and the responses were different I think like for the temper resistant stuff for the security audience it was kind of you didn't really have to kind of give much technical background it kind of just triggered light bulb of you can do this thing out of the box and you don't need to create a whole bunch of tooling for it. For the stuff in Cambridge we actually realised that there's still a whole bunch of things that you actually need to explain which is why I was saying about simplifying the documentation. Removing all that introductory kind of steps of this is how you get started there's still a lot of work to do.