 Okay, so good afternoon everybody, and thank you for coming along to hear me talking about teaching Linux. Lessons I learned from my students, that's you guys, for today at least. So yeah, bit about myself, I've been doing Linux, embedded Linux for 20-something years, written a book about it, blah blah blah blah. But the point about this then is, well first of all, it's really in two parts. First of all, I just want to go down memory-relating a little bit to remember how things started out. And I want to go through some of the dev boards I've been teaching with over the last 20 odd years. But the main point of this really is the second part. I want to talk about what it's like to be a teacher, the good things, the bad things. How I got involved in this kind of thing. And the final part really is, I want to encourage you guys to do the same. You should be standing up here, not me. So first of all then, Linux down the decades. So this is where I started out hardware-wise. 2002 I was teaching using these boards as the target. And this just gives you an indication of the way things have changed over the last 20 years. So this was, this is not exactly state-of-the-art, but it was a pretty common target board. So it's 50 megahertz, PowerPC 823. Actually the 860 was much more popular. There's a lot of products at that time based on the MPC 860. We had 16 megabytes of RAM which we thought was a lot. We had four megabytes of Nor Flash memory, which even then didn't seem very much. So you had to be pretty careful to condense everything down to fit into 4 megs. And then we had the usual things, we had Ethernet, we had RS-222. We had USB, although the USB on that particular board, on that particular chip never worked that well. But we weren't using USB that much in 2002, so it wasn't a big deal. And it had lots of GPIO pins so we could plug in all kinds of LEDs and flash them on and off. That was the main reason for it being there. So what was happening in 2002? So from a personal point of view, I was teaching, embedded Linux and Linux device drivers using this board. And we used this particular board, or I used this particular board for five years, 2002 to 2007, roughly speaking. And basically I was and I continued to do four and five day training classes on site for various companies, organisations or whatever. Business cards available later on. And except that these days it's mostly done online, I mostly do things virtually. So that's the kind of background for what it was all for. What actually was I teaching using? So at this time we were using Linux 2.4. 2.6 came out shortly after this 2003, if I remember rightly. But the board support for this particular MPC 8XX chips was very slow to come along. So I think it was about 2005 before we got 2.6 working on this particular board. It didn't seem to matter so much then. Things changed much more slowly back in those days than they do today. So it was perfectly fine that I was teaching the same version of Linux for like three years. Nobody seemed to worry too much. We were using a tool chain. At that time I was actually getting a binary tool chain from Denx. I did attempt to build my own tool chain a couple of times. But again at that time building a tool chain was a tricky thing. There was a list of instructions about three screens long and you had to tighten them all in by hand. Maybe turn them into a script. But it was a bit kit hut and miss. Basically I was teaching what we call roll your own Linux. So you would start with nothing except a tool chain. Then you compile your bootloader, your kernel, libc and other libraries and the file system. Then you put it all together. That basically took the whole four days. It was good fun. But at that time that was the only way to do it. Build route and open embedded were around. Well build route initially was around 2001. Open embedded came along in 2003. But they were not considered, well from my point of view they were kind of unstable and not really kind of production ready. Apologised to anybody who is listening or in the audience who is working on with those at the time. But they were not generally used. Open embedded was not commonly used until 2007 or 2008 or sometime later. So you're very much on your own. It was kind of putting together yourself. Linux itself was considered a really risky thing by most people. And the quote I give there is, how can you maintain quality if anybody can contribute? I mean Linux, they were comparing it to other less reliable things I think. So yeah the whole concept of open source and contributing to stuff was kind of a novel thing to everybody then. Whereas now it's just a novel thing to most people these days. But then during that time 2002 to 2007 when I was using this particular board, I saw Linux go from basically nothing to by 2007. It was kind of mainstream. It was kind of the thing you would do. It would kind of be the default choice for a lot of projects. So that happened really quite quickly. And what people were using it for. So kind of everything, industrial control, set up boxes, printers, all kinds of stuff was coming along. And the typical story was they had a product already running something like VxWorks or PSOS or DOS. DOS was still pretty common in those days. Somewhat less so Windows CE. I say not so much so because we didn't really have really reliable, really easy to use graphics on Linux until a little bit later on. So that was kind of the start of the road for me. For no particular reason 2007 I switched to using this particular board. So it's from Digi. It's an ARM. It's an ARM processor 9.26, 155 MHz, really fast. 64 MHz of RAM, 128 MHz of NAND flash. And again this is fairly typical of contemporary embedded devices. The ARM 9.26 was very, very popular and continues to be quite popular until quite recently. So I was using this board roughly 2007 to 2010. And by this time we'd actually switched to using Linux 2.6. Mostly I was using a toolchain from Montevista. And then later on we switched to using the Armstrong toolchain. Armstrong being open embedded as I'm sure you all know. But we weren't using open embedded for the main build system. So still basically roll your own. And again that was typically what people did. We're still very much in the roll your own kind of days. And like I said, Tim Sillicon vendor set-top boxes, printers, industrial control was the kind of thing that people were using this stuff for. 2012 Beaglebone Black. So I love the Beaglebone Black. I still use it for some of my classes even now because it's a really nice little package. It's easy to get to, it's nice and open. So yeah, nice little board. Still a single core 32-bit ARM, but again that was kind of typical of the day. Had a GPU, I think this was the first board I had with a GPU on it. It's only later on I discovered what you could do with a GPU, but it was there. Half a gig of RAM, two or four gigs of flash memory. And yeah, mostly using Yocto. Yay, Yocto. So finally by 2012 Yocto was kind of becoming mainstream. I mean Yocto only came about in 2010, so that's fair enough. And also Buildroot, I don't know if any Buildroot people are here. So as you know, Buildroot went through a bit of a lull. But by 2010, 2012 it was on the up. And it's also, it remains one of my favourite build systems. And then Android happened. So I started running Android on Beagles in, well about 2012 actually. It was one of the main reasons why I switched to using the Beagle. So Jelly Bean through to Nugar. Then in 2017 I switched to Raspberry Pi. So now we're getting to kind of more modern things. Everybody knows what a Raspberry Pi is. And the Pi came along mostly because I was doing more and more Android stuff. And I couldn't get anything beyond Android 7 to work on a Beagle Burn because it doesn't have enough memory and the graphics chips, the graphics libraries didn't work and so on and so on. And that pretty much brings us up to date. So that's kind of the end of my stroll down memory lane. But we've got to a point now where Linux is dominant. It is the default operating system for all mid and high end embedded systems. And because of Android it totally dominates mobile. And increasingly, well no increasingly, it also dominates automotive. So most vehicles are running Linux or Android or both. So hey, we won. So that's the background and that's what I've been doing the last 20 years. But really what I want to talk about is why do I do this, how do I do this and what are the good things and the bad things of standing up here in front of an audience. So the first question really is how did I get into this stuff. So I didn't wake up one morning saying, you know what, I'm going to become a teacher. That doesn't happen. It was a random sequence of events as everything important in life is. Life is basically a random thing. So the first step was I started doing some stuff with Linux. So ran about 2001 or something. I was working on a project with a customer. And the obvious choice for it was Linux. So somebody said to me, this Linux stuff would do that. I said, what the hell is Linux? Went and found out. So I was, and I looked at Linux and I thought, hey, this is quite neat stuff. Actually at one point going up a slight tangent, I remember sitting down in my little office in my backroom in my house thinking what should I do? And I thought I could do Windows CE. A lot of my friends are doing Windows CE and they're making lots of money from Windows CE. Maybe I should do that. And then this Linux thing came along and I looked at that. I thought, screw Windows CE. I'm going to do Linux instead. That's a lot more fun. So I started doing that and initially I made zero money from it, but eventually it kind of caught up a bit. So that was, you know, so I was doing Linuxy stuff. And then I went to a little trade show in the UK and it's called a Tabletop. I don't know if you've ever been to Tabletop shows, but essentially you pay a huge amount of money to rent a Tabletop and you put a few demos on there and you have a poster explaining who you are and that's kind of it. So I did that, but I didn't do it very well. I had a little board running a web server and I had something on my laptop showing web pages, but nobody really understood what that was about. And I had a picture of a penguin, you know, tux. But nobody knew what tux was. People just walked straight past thinking of penguin guy, whatever. So it wasn't initially a very successful show and I was quite disbondant by it. But then the one person actually did come and talk to me. Actually was a guy who ran a training company. And we had a brief conversation. I explained what the penguin is about and how Linux was going to take over the world. Yeah, yeah, yeah. And we kind of exchanged business cards and then he went quiet and then about 12 months later he phoned me up and says, that Linux stuff you were talking about. We've got a bunch of customers who want to know about Linux and we need somebody who knows what to tell them. Would you like to do it? So I said, yeah, okay, whatever. I'm kind of skinned, so I'll definitely do it. So that's how I came to become a trainer. Was it easy? Hell no. So initially, so not only was I actually doing the training, I had to write all the materials to start with because there wasn't anything to start from. So I just sort of said that tapping away. How do you know how long it's going to take to run training courses? This is build as being a five day class. So lots and lots of stuff. That's got to be it. So the first time I did it, we actually ran out of material after about four days. So day five was basically a recap. Anybody have any questions? Please? More questions? But it worked out okay. And then I kind of got into it. So what are the problems with standing up here like this? So, you know, I still suffer from this stuff. So there's a constant fear that my biggest nightmare, my kind of literal nightmare, wake up in the middle of the night sweating sometimes, is being in the room and with everybody else knowing more about the subject I'm trying to teach than me. In practice, it doesn't actually happen. At least it hasn't happened so far. Because they wouldn't be taking the class if they do stuff like that. Even if they do know certain parts. So you always go into a sort of training class. There's always some people who worked on some parts. So you'll find somebody who is an expert on Bluetooth or somebody who's an expert on SPI or whatever. But you never find anybody who has the, or you seldom find anybody who has the kind of continuum of stuff. So that's kind of what I'm doing. It's kind of building the road map so that you can connect all the various towns together. So that fear I kind of overcame. The other big fear is the fear that the people I'm teaching are smarter than me. And then I realized, of course they're smarter than me. I'm not sure. I'm smarter than me. I'm not a smart guy, but any means. So you just have to get over that, you know, whatever. You guys are all smarter than me, but whatever. I am the guy here who's talking to you. So you better shut up and listen. I have control of the clicker. So those are the fears. You kind of get over it, but it's still a bit tricky. What have people gone to know? Well, I don't know, I kind of run out of bullet points here a little bit. People want to know, certainly in the early days, when I started out doing the Linux thing, people mostly want to know what the hell is Linux? How does it work? Can we trust it? Can we actually use this to build a real running product? And that was really my role was to kind of say, yeah, sure, don't worry, it works. Eventually it works. So the next few slides I want to have a little look at kind of techniques of teaching and the various things that you can do. And I'm going to start off with the good old learning pyramid. So I'm sure you've seen this before. So this is rates of retention, roughly speaking, for various mechanisms of delivering content. So the one at the top there, lecture, this is the worst way of learning anything. So less than 10% retention. So, yeah, what was my third slide? Hands up if you remember what was on my third slide. See, nobody. I could have skipped that slide completely. You wouldn't notice. And you won't remember this one either. So the point is that just talking with a bunch of slides, it's kind of quite fun, but it's not an effective way of retaining information. So then going down the pyramid, reading stuff, sure that you've got to put some effort into reading, audiovisual, whatever. Demonstrations is interesting. So we tend to do a lot of demos as we're doing our talks. Now I'll come back to that a little bit in a couple of slides time. But actually watching a demo is more valuable than just somebody talking. So that's useful to know. Discussions. So if you can get some discussion going on the topic amongst your audience, not now, but that's a good way of retaining stuff. And then we get onto the big ones, practice doing. The best way to learn something is to do it. So we spend, as teachers, we've spent a lot of time preparing practical sessions and exercises and challenges and whatever. And then the biggest one of all is teach. The best way to learn something is to teach it to someone else. So that's how I learn things. And I'm going to come back to this again. But really I would encourage you to get all the way to the base of the pyramid and to do more teaching. It is the best way to become proficient in a topic. The thing is that when you are preparing materials, how do you put things together? How do you tell a story? Fundamentally there are two ways you can do this. You can either do top down or bottom up. So with top down, you basically start with the fundamental principles and then you go into more detail and more detail and eventually you get to something. So you can imagine that this would be like learning C++ by learning the syntax, learning the variables or the different ways you can make assignments or the different whatever you can do with C++. So you'd spend like four days learning the syntax and then on the last day you'd write Hello World. Obviously that's not going to work. So top down deductive is one approach. But it is quite attractive to a lot of people when you think about presenting something, you say well I'll start with the basic principles and then we'll work down and eventually we'll deduce the point where we should be. It doesn't work by itself. So you go to the opposite extreme and you go to the bottom up. So you say okay well let's just start with examples and then by if I show you enough examples you will work out what the syntax is. So this way I would teach C++ by giving you lots and lots of snippets of C++ code and you would eventually work out what the syntax is and what you kind of can't do. Obviously that's not also not a runner by itself. So the idea is to combine the two. So this is kind of obvious but it's also not so obvious when you sit down and start writing material. Keep this in mind that you need to start off with a framework, diagrams and then give some examples. Say well this is what it looks like and then from that you can then say well let's tear this Hello World program to pieces and see what each line does and then you go back to more principles and basically you kind of keep on flipping between the top down and bottom up. Or at least that's how I do it. Learning by doing. So this is the 75% mark on that pyramid. So unsurprisingly the best way or a very good way for students to learn something is actually to try it out. So it's all very well me saying that if you do these things you will generate a Linux kernel or something. But actually building your own Linux kernel is a completely different topic. So you're going to remember that much better. So it's important to intersperse the kind of just me boringly talking about stuff and actually have a chance to try things out. And from the students point of view I think people often get a little bit nervous about doing this because they think oh I might get it wrong. Actually it's good if you get it wrong. Well not on purpose obviously but making mistakes is good. Because turns out you actually learn. If you make a mistake as long as you learn by mistake then that's a learning experience. So one of my favorite phrases is everything is a learning experience even when it goes terribly wrong you are learning things. So when things go wrong that is good. So long as they don't go completely wrong. And also when you're actually there and the students are doing the labs and whatever it's a great opportunity to try things out kind of tweak things a little bit what happens if I do it this way around whatever it's a great kind of sandbox where you can try stuff out. Live demos so I think at 30% on that pyramid it was demos. So demos good and bad. So the thing is I know some lecturers who actually do their entire lecture as a bunch of live demos. No slides, no nothing, they just stand there and say well here's how you write this program and he's writing that program whatever. It's very impressive, I couldn't do that. It requires a lot of concentration and a lot of ability but it isn't a solution. As we said live demos they're better than just listening to somebody chatting on but it's not a substitute for actually doing the stuff yourself. So don't kid yourself that doing live coding live demos is actually solving all the problems. It gets you a little way there but you still need to actually sit down and do the stuff. So problems with live demos if you're just doing it kind of on the fly as we are here then people will misremember what it is you typed. You say oh this is how you build a kernel it's gone off the screen people maybe didn't notice that or maybe they misunderstood why you're doing this maybe you didn't explain exactly what kind of kernel it is you're building or whatever. So it's easy for people to go and misunderstand the reason you're doing this demo. However live demos do have a function so I do use them myself quite a lot. The great songs you keep them short and keep them snappy and keep them focused. So if your live demo goes on for more than a couple of minutes you're probably doing the wrong thing but it's great to say this is what it really looks like. Be aware that when you type make to build your kernel is not going to happen instantly you'll need to come back in a few minutes. The other thing is I've seen live demos work really well if you are recording the session because the great thing there is that people can rewind and pause and kind of review what you do. So the command that kind of shot off the screen when you hit enter they can kind of go back I still don't think it's brilliant but some people like doing it that way. Questions, questions are good. We'll come to this in a few minutes. So it's from a presenter's point of view it's great because it means that I get some ideas to what it is you're interested in, what are the problems maybe I haven't explained something very well. The other thing is that particularly if you're doing a a long kind of daylong presentation as I often do it's a great opportunity to stop talking for a while and take a drink of water or something. Point three is a little bit questionable perhaps. I've written here there are no bad questions. This is not literally true let me just say. But yeah feel free to ask questions is what I'm trying to say. So when in a couple of minutes time I say are there any questions I really don't want the room to go quiet. You must have a question because there have got to be questions I haven't explained everything perfectly obviously. So yeah there are no bad questions as long as the questions are on the topic under consideration here. And from the presenter's point of view the teacher's point of view answering questions is also a little bit of a worry. So will I know the answer? So the point here is that you have to admit if you don't know the answer to the question. So if I don't know the answer to the question I'll just say I don't know but I will find out and get back to you. But there's no point making answers up with some people I know do do especially politicians. Key point then learn from your students. So this comes to the pyramid the ninety percent this is how you learn. And I mean sometimes I've been teaching the same material over and over again my dozens of times. And yet even if you've done the same class a dozen times you still get the unexpected question. Somebody will say the 12th time you do it you know some whatever and you'll think no I never thought of that before I never nobody ever asked that question before I never never asked the question myself but it's a really good question. So that kind of triggers you and you think well OK I really ought to know you know what exactly is an eye note that somebody did ask me one time I thought I don't know it's a thing let me find out exactly what thing it is so it kind of triggers you to go down a particular rabbit holes which is good. The other thing is unexpected results of labs so this happens to me quite a lot. So I look over somebody said it's not working and I look over the shoulder and there's an error message there which I've never seen before. I don't know how have you done here. But again it's interesting to kind of probe into that and find out how did they get into that situation. Is this something you know this is something I should be aware of. This is something I should warn. There's a bear trap here I should warn people away from perhaps. So no again it's part of the interchange. You may not realise this but when somebody is teaching you they are also learning from you the whole time. Be open to comments and criticisms. So if you spot spelling mistakes or errors in my slides then tell me about it. I really really want to know because not now. That was on purpose obviously. So yeah. So interesting little side topic on that. One time I was teaching a particular bunch of people really really really engage should we say and towards the end of the training sessions one of the lady comes up to me in the coffee room and said we've made a list of errors in your slides and I said oh yes. She said I'll send you a link if you like. I said okay a link to what. I said well on the first day we set up a web server and a chat bot and we've been kind of recording all the mistakes you've made on that. We'll just send you a link and you can just copy it. So I said well thank you very much. Thanks for the effort. But so yeah it's fun. Sometimes you get somebody who has domain knowledge or something I'm trying to explain and they know more about it than me. Not a problem. As long as they're prepared to explain it to the rest of the class they can take over. Fun things that happen. So another couple of anecdotes not particularly relevant maybe but I remember one time so the standard thing you do in any embedded lab the first lab you do is to turn an LED on and off. You know it's still fun. I really love flashing LEDs. There must be something in my brain. So one particular time we do this exercise and this one group instead of just turning on and off they got it to fade. So it kind of faded slowly from off to on and back again. I said how did you do that? Oh we just post modulated it in software using this little loop here and that loop there and whatever. I thought wow that's pretty impressive. I've never seen anybody else do that. So that was neat. And the other fun thing was one time we used to have I don't know if you've seen these you can get little toy missile controllers they're USB things and you can move the launcher up and down and it's often right and then they fire a little missile with a foam thing on it. It causes chaos when you do this with 12 people but it's quite fun. So one particular bunch they had not only done that they'd written the control program for the missile launcher but they also had integrated open CV and face recognition. So as you walk past it it will kind of track kind of lock onto you and it's impressive too. They got extra marks of that. Yeah so yeah teaching is fun it's not totally easy but it's worth the effort. So I've got a couple more slides and then we will do the Q&A. So what are my takeaways? You've always got to have takeaways. So seriously one of the things I wanted to get out of this is to encourage you guys in the audience to think of becoming a teacher maybe not full time but doing it sometimes. So teach people, lead discussions, guide workshops. It's fun it's a great way to learn as we've discussed it's a great way of helping your colleagues in within your company and also within the community and fundamentally we need to spread the word on the stakes. And generally speaking if you speak to the people who are doing training including say Dullos I know are here and Linus Foundation or whatever they always say it's really really hard to find people who can teach. So consider that. So call to action I want you all to go out and start thinking about giving talks within your company standard lunchtime things maybe attend local meetups for whatever is interesting to you upstream something contributed meetings ask good questions be engaged teach others. So that is basically it we have time for some questions the slides are uploaded to that place there but they're also in the in the shared thing. So that's me done so I think we have time for questions who wants to lead off and I'm afraid Marta you'll have to deal with the microphones on normally on the microphone size side for questions we have microphones on both sides of the room. So you can do queues for questions. I have one from the queue from the visual audience it's more of a comment would be interesting something I'd like to share about learning memory is the residue of thought when we get stuck on a problem have to think and work hard to solve it we are more likely to remember what we've learned. That's that's almost poetry. Yes I'll include that in my in my slides totally you this is a challenge to me when you can get coming up with with with the labs you got to think of something that's interesting relevant difficult but not too difficult so it's a difficult it's a difficult thing of combination of things you need but that's the ideal thing so what you do in practice is I always have like three labs so there's one lab which is basically copy and paste and everybody will do the first lab the second one is something that's a little bit more challenging but which covered which was covered on the slides so it requires you to read the slides and do some deductions from that and then usually I do a third one which is kind of tricky which is extending that and doing something something that's going to cause you to to think a little bit How do you avoid getting the exercises to be basically kitchen recipes for people how do you make them so that they have to think and have to get the knowledge in because I have had people that basically wanted a kitchen recipe I want to do this, I want to do that and they want the answers in the exercises and I hate that so that's a tricky thing so that's what I say I try to structure things so there's one copy and paste thing which everybody can do and then there's one that's going to they're going to have to think a little bit about and then there's another one which you're going to have to think a lot more about and the other thing is I always give kind of solutions so if somebody is is totally stuck you say well go read the solutions guide that is a copy paste solution to the exercise so if you really stuck go do that but really don't go to that straight away have a go at solving the problem first and then come back to the copy paste solution we have like two minutes hi Chris on this side thanks for this love to hear your experience on that just curious if you see any fundamental difference between teaching in a scenario like this where you're giving a talk just a one hour talk versus the longer term training sessions that you put together is there anything fundamentally different or just anything fundamentally different in the way that you present the material yeah it's totally different experiences so if you do a presentation like this then first of all you've got a very limited space of time and we're about to run out the other thing is that to be honest you've got to be a little bit entertaining so you want to put in a few throw away comments in because as well as being here this is also a little bit of entertainment so I do approach them totally differently ok on the slide with the pyramid you made a point that a lecture has actually worse retention than just reading in that case what's really the point of doing lectures why not just maybe hand out some reading material and then do a Q&A session about that I don't know why are we all here so I mean there are two ways of looking at that so first of all in this kind of environment the point of the lecture really is to bring everybody together and to give a focus on a topic so you won't remember every word that I've said but you can go look at the slides and it kind of gives you a lead in and kind of an interest in it otherwise if the presentation sorry if the entire conference were just a bunch of slides on the slideshow or something nobody would pay any attention so the lecture is basically a focus so I'm getting the stop now sign from Marta so I better stop but anyway thank you all very much and