 Hi, I'm Dave Stewart. Welcome to the OCTO Project Developer Day. We're very excited to have you here. We're trying a little bit different format than we've done on some of the previous developer days. We think this hopefully will be helpful for you to really advance what you're doing with the OCTO project. And also, as you see things that maybe you could see improved, we'd love to encourage everybody to work together to make this a phenomenal project. I'm delighted to have you all here. I'm David Stewart. I usually live up in Oregon. Tracy Urway is also here. She usually also lives in Oregon. She's been in the back of the room. I'm going to start out with a quick introduction for the Developer Day and then she's going to give also a little piece about some of the other advocacy work that we're doing. So, without further ado, I actually got to confess I didn't do these slides because I ran out of time. And I'm really, really grateful to Jeff Ozier-Mixon for doing the slides because I'd like totally ran out of time. So the way the day is going to be structured here is we're going to do a brief introduction. That's me. Then we're going to have several technical presentations on important topics that I think will hopefully really help you out. And then we've structured things here so that we've got an hour where we've dedicated so you could have one-on-one or small group discussions on particular topics. So we're actually going to set things up so that you can actually connect with experts kind of directly. And so we're treating this as seeing how this will work. Hopefully it will really give you good, you know, answer to your questions immediately and get some really good one-on-one interaction going. So that's sort of the goal. And then, you know, drinks and food and that sort of thing afterwards. So this is, let me kind of talk to the technical talks in red. So first we're going to start out with a topic of working with the kernel, which Tom Zanussi is going to be presenting. And, you know, there's some things you need to kind of be aware of working with the kernel tool. So I think this is going to be very good. Then we have this sort of trifecta here with Kuhn, Camaraj and Beth Flanagan talking about workflow. One of the things that when you have a fairly, we have a fairly powerful set of tools I think in the OctoProject, but we haven't, you know, defined a very specific workflow like do this, do this, do this, right? And so one of the things that we, but we understand people kind of come to the project and they go, well, help me out a little bit. Give me a little bit of a clue as to how to hook together the tinker toys so that I actually have something that makes sense, or I may change it, but just give me kind of that general idea. So I think what these guys are going to be focusing on is within their expertise on workflow, which they have considerable expertise. I think they'll be able to help a lot with that. After a break, Camaraj is going to be talking about advanced customization. Cam, I don't know if this is the same version of the talk you gave in Barcelona, but it was an awesome talk. I thought it was incredible. So this will be, not the name of the rest of them will be bad, but I really, I thought it was an excellent talk. It was really good. And then Jessica will be here to talk specifically about our using Eclipse. We've tried to, you know, include that as a part of the developer experience. It's not a required part. People are very happy developing without Eclipse, but, you know, the Eclipse support I think has been a very powerful part of the developer experience. And we're trying to extend it as well, which I'll talk about a little bit in my intro. Right, then five to six is where we have this really, this green zone here is the one-to-one, and we're going to set this thing up. I don't know exactly who's going to do it, but I understand there's going to be different tables designated for the different topics. And then we'll do, at six, wrap up refreshments, social gathering, et cetera. Anything else we should cover that we're not? I always like to ask. I don't know if anyone will actually say it. All right, I'm going to talk about, give you a quick introduction to the OCTO project in 15 minutes. And it really is an umbrella project. Actually, Coon and I were talking at lunch a little bit about kind of how the OCTO project is an umbrella project, including a number of other open source projects. And so how many have already heard my introduction about the OCTO project? Only a few in the back of there. Oh, awesome. Okay, so have you already heard it? Please bear with me. It's a shortened version. For those of you who haven't, I'll do my best to answer any questions you might have and not be too confusing. But it really is both a collaboration space for many projects, as we've talked about. And the main, the three main things I talk about with the OCTO project is, it's a build system, it's content, and it's a developer experience. So we'll talk, we'll zoom into each of these in a second. But it really allows, each of these in some extent can be thought of somewhat independently. We support all of the main architectures for embedded, ARM PowerPC MIPS and X86. For several of these we have different 32 and 64-bit variants as well. Even for X86 we have the X32 ABI, which is a way to use the 64-bit version of the registers without having 32-bit or 64-bit addresses and immediate so that you actually have a much smaller footprint but you get all those registers to schedule against. It's also a collaboration space. I apologize if I cough a lot, I apologize for that. I just came down with something a few days ago. So I'll do my best to not hack too much. I think I may grab some water though first before I do that too much. Thanks. I graduated from the SIPI Cups many years ago, but thank you for that. It would be nice to have a bottle, but I don't. And part of this is a common place to find board support packages. Now people could put BSPs really anywhere associated with the projects they're doing, but we sort of wanted to have a common place where people could find them as well. One of the cool things about the project is it's actually standardized what a BSP for a Linux OS should look like. In fact, I was just talking to somebody last week and they said even for other OSs that they're trying to get working on hardware, they often look at our BSPs as a reference. Is there how to pull all the things together? Oh, boy. And then we had the Eclipse plugins. So I was having dinner next to you last night. I think that's what did it to me. I think you were kind of... So really, why use something like the Yocto project? Because many people have done embedded Linux. Maybe they use something like a desktop distro, like a Fedora or Ubuntu or something like that. Or maybe they might use Android. Or a lot of people have been... Because there hasn't been anything that we've kind of been able to all collaborate around before. There are all kinds of little systems that are out there for building embedded Linux. So the hopeful idea here was to actually have something that would solve a big problem that was, well, you can hack something together, but what can you do if you want to take it on to the next project, right? This is something which with any of these operating systems, well, I can hack out the things I don't need. Well, maybe I don't need a desktop, but I do need this and I don't need that. All right, I got it hacked up going. But then it's like, okay, new version of the underlying OS comes out. Well, now, do I have to redo everything again? So as engineers, I sort of feel like we've kind of taken an engineering approach to this, which is have something that minimizes the amount of rework you have to do when there's a new hardware board that comes in or a new release of upstream projects or any of these advances. You don't have to completely redo everything when you go on to the next thing. So we really designed this for you doing, establishing a long-term, hopefully profitable business doing embedded devices. And so that's kind of the idea behind this. So these are some of the things, you can always hack stuff together, but if you want to turn on debugging for random sources, maybe, like I said, upgrade to newer versions of things. Maybe you want to build something with real-time enabled or switch to something else, different tool chain, different hardware. How much of stuff do you have to completely redo? This is one of the things providing a source offer with GPL, particularly GPL license source, right? You need to provide, by the terms of the GPL, when you have a Linux-based device, you need to provide all the sources that went into, all the GPL license sources that went into making up the OS. You need to provide that source offer. Well, if you base what you're doing on Fedora, trying to find all the source RPMs that made up what you just built, and then making sure you have that someplace, and what we do in the Octo project is, through very simple automated mechanism that we outlined very clearly, how to create your source archive and a source license manifest. So we can produce those things that you can then put in a place to satisfy the source offer, and it's really designed for doing that sort of thing. You know, filtering out license versions. Some people have kind of a, we like the GPL, we think the GPL is great. Some people don't like GPL v3. I'm just talking to Tim Bird. He says he stopped being diplomatic. He just doesn't like GPL v3. You know, we're fine with it either way, but if you want to filter out all the GPL v3 sources, we have a single line you can add to a configuration file, or a little checkbox you can check in the build tool. And eliminate all the GPL v3 code. So that's an advantage in certain instances. And then, you know, if you want to move to a commercially supported OS, I mean, a lot of us might be in the situation where we can create a proof of concept, and then it's like, well, I need to get commercial support for this thing. By basing it on Fedora, you know, I'm not sure Red Hat's going to give you the time of day for supporting an embedded device, right, based on Fedora or Red Hat. Right, if you base it on Android, maybe, I don't know, getting commercial support for that thing might be tough. The great thing about the Octo project is we've got commercial support from Wind River, Mentor Graphics, Montevista, and NIA, and a larger ecosystem. So you can get commercial support for what you're doing. Okay, so who is the Octo project? It's silicon providers. It's, you know, OSVs, embedded OSVs. It's people who are making devices, and it's also just people in the community, the open-embedded open-source community working with us to really make, you know, really get everything together to make embedded Linux great. All right, so one of the exciting things is we're at a point in history where we're actually all able to collaborate together. And, you know, we took the best build system we started really working with that and started really honing the content, the developer tools, gaining, you know, cooperation. And that's been very exciting to see. I think we finally see everyone, you know, focusing on this. And then we have some other open-source projects like LTSI that have joined with the project as well. So this is sort of the logo salad of people who are on the advisory board. The way we're governance structured, we're part of the Linux Foundation. We're actually a workgroup under the Linux Foundation. We have set up the governance so that it's as a regular open-source project, right? It's all about meritocracy. So we have the equivalent of Linus Torvalds, and that's Richard Purdy. And so, you know, he has his lieutenants and maintainers and technical leads under that. So that's all like a normal open-source project. We do have an advisory board. We ask if somebody wants to contribute to the project in an advisory capacity, providing us feedback and input. We have an advisory board and it costs some money. It's not an exorbitant amount of money. It's not like it's millions of dollars. I don't remember how much it is, like 10,000 or 40,000, depending on which level of membership you're at. And you can kind of see the groups that have gone to that level. We also have established a way that we can build a broader ecosystem into two programs that we call Yachter Project Participant and Yachter Project Compatible. So if you have a software product, for example, like we have tool chains, we have people doing operating systems, we have people doing libraries that are Yachter Project compatible, there's a list of things that you fill out on the website and you can use that and actually become part of the overall community. For participating and saying, hey, I've got some services I want to be able to provide to others, I mean, we have the Yachter Project Participant, which lets you, again, get you as part of that bigger ecosystem. So there's a lot of participants and there's a lot of probably people who are using the code who will never know. Steve Sackerman said to us one time, there are a lot of people using the code who you will never know who they are because there's no reason why they have to tell us, right? So I constantly am hearing about people. The funniest thing is people in my own company, you know, we'd hear about a piece of email that would bounce from the other side of the plant and say, hey, we hear there's some guys over there and you're part of the company working on the Yachter Project. Well, duh, yeah. It's like my whole life these days, you know, and it's like we've got a whole team. Why do you ask? Oh, yeah, we've adopted the Yachter Project for our random XYZ project. This has been very cool to see. But again, it's typical that I think the sort of thing that's happening all over the place now. You know, so, yeah, in five minutes or less. I love the way Jifro has given me. I think I hit the 15 minutes on that one. All right, so let me pause for a second before I talk about these three bits. Are there any questions about anything that I just had? No? Yes? Any questions about the what the Yachter Project is? You see what it is we're trying to do? All right. Let me just zoom in on a few of the things that go into the Yachter Project. As I said, I usually describe it as build system content and developer experience. It's actually more than that because, you know, we also have documentation. We also have, you know, BSPs. We also have, you know, QA that gets done. We're putting out a release every six months. We're coming up with our sixth release in April. So we've been bringing those out pretty much like clockwork. We also have, you know, maintenance releases that we bring out for security CVs, primarily. Other sort of important patches that are needed. So there's a lot of other stuff but I generalize it into these sort of three main buckets. So as far as the build system is concerned, BitBake has been an open source build engine available for a number of years. BitBake is actually a highly efficient, it's basically a python script with a number of classes that let you, you know, customize it for what we're trying to do in the octoproject for building Linux. So you have classes for example that take care of all the things such as fetching sources or figuring out metadata and things of that sort. So it's highly configurable. It's also, you know, highly efficient. When you could build a Linux system on a desktop in 88 minutes, something about back to the future. 88 minutes is what I, because I just remember from our last release criteria meeting. That's pretty good from building everything from sources. So it's highly, it really is highly efficient. There are several other utilities that are separate projects as well. Swabber is a tool which will actually can go through and validate that you have no build system infection. So that's one of the things that you can actually double check and will actually monitor all the opens on the system to make sure when you're doing a build you don't, you know, have a problem there with infection from the build system. Pseudo is, you know, how you, the method we use for setting, you know, how do you create a root file system while not being root. So you have to create a whole bunch of binaries in our own, you know, set UID 0, right, or user ID 0 and things like that owned by root when you're running a build not as root, right. So you don't have to be the root user to run a build. So Pseudo is how we take care of that. Pocky is essentially a reference distribution definition which takes in all of the pieces that we have and provides you as you know, a place where we can do QA. So we build Pocky, we actually, when we're releasing the Octo project, it has actually called Pocky when you look at the source repository, the Git repository as well as the releases, it says Pocky. If you're creating your own distribution, you can take the Pocky metadata which I think is Meta Octo and then just rename it to something else, right, and then you have the starting point for your own distribution, right, so, but we needed something for which to do our QA around, so that's what Pocky is. We also have a, I think a really terrific auto builder infrastructure, it's getting completely refactored and redesigned that there'll be a release with our 1.4 release, Beth assures me, fingers crossed, that will actually be much easier for you and your projects if you want to set up repeatable builds, right, the auto builder is set up so that it will actually build all of our targets every night, which is remember, we've got, you know, four main architectures, we have five different footprint sizes, we've got LSB for the, you know, everything that could go into an LSB system, we have Sato, which is a sort of a graphic, you know, basically it's a GNOME mobile-based thing with X, we have Minimal, which is busybox-based and headless, we have Tiny, and Tiny is like, I think, five megabytes or less or something like that. I missed one. What did I, oh, World, which is, you know, all the packages we have, right, so if you can kind of think about building across all those architectures, plus a few, so we have 3264 bit on a few of them, all the footprint sizes, all the different variants, we have debug versions as well as non-debug versions, so we're doing all that stuff every night, it's a lot of build, but the auto builder is basically able to handle all of this and Beth is setting it up in the new release, and she'll talk more about this, I think, in her session. The developer experience is really about some of the things beyond just, you know, that facilitates not only you as a system developer, but also application developers, so part of the concept of workflow is there's some people who are actually developing the image that will go on the final device, right, so they may be doing some debug, they may be figuring out which packages go in, if I got too much space, what do I need to throw out, things like that, then there's another type of developer that's an application developer, now we typically see different skill sets with that sort of person, a smaller shop, everyone, it's maybe one person that's doing everything, but oftentimes an application developer maybe has more expertise in making things, you know, behave properly in a particular domain, or maybe it's user interaction design, or maybe you know, more appearance that's more appropriate, it's things are set up here so that you don't actually need to rebuild Linux if you're an application developer, because if you're rebuilding all Linux, right, it takes a reasonably beefy desktop machine to be able to do it, or something like a laptop, right, you say you desktop client sort of machine, maybe you want to not have to set up all your application developers, so they all have to do that, so you can have a single person on a project do the bit bake, and then you have your application developers that can use the SDK that's created by bit bake, so that's what this application developer toolkit is designed to, which is not actually listed here, oh well. We also have a build appliance, this is set up so that you can very easily download a VMware guest, and has everything built in, so that once you download that thing you can basically boot it straight up into a graphical build experience and be building it pretty quickly. Without something like this, well you need to make sure you have a particular version of Linux, or certain packages installed, to try and short circuit that as quickly as possible we created this build appliance. Now this thing is also a concept we're extending on, because there's some things that you can actually use this thing in more of a headless manner to be able to, for example, use Eclipse on a non-Linux operating system. One of the things I think is kind of interesting, I had somebody just yesterday, maybe that guy looking at me right now and smiling at me, who said, well I'd love to be able to do a build on my macOS, right? And so using Eclipse within the Mac, conceptually we're going to be allowing you to use this thing, so that the build part of it can actually go on in this image, and this could be running in VMware or it could be just running on another machine in your lab somewhere that's just dedicated for builds. So we're kind of extending this concept as part of the developer experience. We've got Eclipse tools. You can either use this with do your app or system development with Eclipse or not as you choose. And as I said, we're extending this so you can run it on Mac or Windows or any other OS that Eclipse will run on. Hub is a graphical user experience for BitBake, so it lets you so you don't have to go in and figure out what a bunch of config files are doing, how to edit them. So it kind of simplifies that process. And we're coming up with a web version of this as well. We're working with a design agency that's helping us out with this, and it's all open source, and it's really kind of a community development effort, so if you want to join the mailing list that's talking about this, this would give a great way to participate. I'm actually going to show a screenshot tomorrow morning. I'm doing a little keynote tomorrow on the embedded lens conference. I'm actually going to show you a screenshot that got people incredibly excited. People who are typically, let's call them a gooey skeptical looked at it, and they said, wow, if we had something like this, I would use it. So we'll show you a little bit about what that's about tomorrow. But we're continuing to develop that. So there's a lot in terms of the developer experience, and I think the other part that doesn't quite go into this, if you think about it, is that if you have a desktop Linux build situation, you can actually develop code that might go on your device. Maybe it's not something that you want to share out with the world. You want to keep it kind of close to the vest. You can do it on your desktop, and you don't have to set up an elaborate server infrastructure. So that's part of the developer experience. It can be very small, or you can scale it up to a large sort of situation with some of these things like the auto builder and the build appliance and some things like that. So it's a pretty scalable sort of environment. And then content, in this case, the metadata that comes with, that we provide with the system is really a lot of what we call recipe files. These recipe files end with .bb. What the idea behind here is that they list at the most minimal level it shows what's the URL for the sources for a given package, what's the source license, check sums for the source and the license, and then overrides for things like for every step in the process. So for each of these things we'll do a source fetch, patching, compiling, packaging, installing and packaging. So for each of those steps you can override them, append to them, prepend to them, etc. So that's essentially add additional files like, for example, in the install set, maybe there's a specific file you want to install in the target you can append that to the install step. So each of these steps is really designed for maximal sort of configurability and adjustability. So like I said, we've designed this to make it so that you can construct a working system, right? Building a working Linux system. This is where the difficult part comes in that we've hopefully done the hard part, which is figuring out the versions that work together, created the patches that work together, and this is the thing that we're doing regularly and that we're releasing every six months. And all of them really are configurable in layers. And so that you really can override any of the metadata that we've provided in a layer. And so you can say within that layer I want to disable these things or enable these other things. And so we have a number of example layers that I think are showing how this concept works. All of this is part, a bunch of this, a large part of this content is actually part of an open source project called Open Embedded Core. So this is the core metadata for the open embedded project. So we work with the rest of the community to really make sure that that core metadata is really solid. And then there's other content, EG Lib C is part of the Octo project. That's part of the umbrella. Matchbox is another example. There are a number of these sort of small open source projects that are part of it. And we also have a number of starting points that we've developed so that you don't have to start with those five footprint sizes I talked about, those five starting points. We actually build on those to things like Baryon, which is a starter kit for network attached storage. So if you want to do a NAS, start with Baryon. That's a layer on top of probably minimal I'm guessing because it's headless. Has web-based integration, has all of those things built in. You add a BSP layer away you go. Web kiosk is a HTML5 delivery mechanism, but it's basically a starting point for web kiosk. But the compatibility is all the way up through HTML5 as well. The multimedia starting point, this is how to create things like a DLNA, DLNA, which one? Okay, DLNA. Anyway, multimedia. Virtualization, the meta-virtualization layer, there's actually a talk about meta-virtualization this week at ELC. This gives you a starting point for creating things like a KVM guest, a Zen guest, etc. There's an automotive layer that's being maintained by Wind River, I think. Is that right? I think that's right, yes. There's a robotics layer. There's a number of these that are both there now and coming soon, so you get a really clear starting point of a place to start so you don't have to invent a bunch of stuff, right? But if you come up with something else, we'd encourage you to do so and share it with the community. This makes it a powerful thing when we're working together as a community. Okay. That was five minutes on that. I could easily take an hour just talking about this. This is a work of art, I think, but anyway. But basically what this shows is the workflow for the project, for BitBake. The blue box is really BitBake. It's really the inputs here are user configuration, things like I want to configure which layers I'm going to use, or how many processors I'm going to use on this build, right? The metadata that I talked about each of those recipes, plus the patches, then you have like a BSP configuration that would go in, and then other policy configuration that we want. The default you want to use for your distribution. Then you type BitBake in a target, and then it will go through and it will pull. The first thing it does is source fetching. BitBake actually understands all the popular source code management systems and a bunch that are not particularly popular either, but that are still supported. Or you can pull it from just a source mirror. If you're working with a group, you want to make sure everybody uses just that version of the sources rather than pulling them down from the internet, you're going to set up your own local project for that. You fetch the sources, apply the patches. If it's an autoconf project, it'll do autoconf. Otherwise it's doing the compile and installing a piece. There's some output analysis for doing packaging. I always thought it was kind of funny every Linux project has its religion about which packaging you use. Is it DEB or is it RPM or whatever. One of the things I love about this is that we don't care, use either one. We support them both. Plus another one called IPK, which is a more simplified sort of embedded style packaging mechanism. You can pick either one that you want. Those get populated into a package feed and then out of the package feed the image is generated so you get bootable images. This SDK is really cross tools and assist root so that you can then do application development. That's application development outside of, so you don't have to rebuild Linux. I think that's my last slide. I probably did that faster than I was expecting to. I was hoping my voice wouldn't give out. Alright, so what questions do you guys have about this? Yes, please. I see someone from TI with his hand up. He can probably say, why don't you speak to the microphone there, Bill? Come on. Thanks. Bill Mills, member of the advisory board for the Yocto project. Yeah, so we started the Yocto project before Yocto project started. The original versions used open embedded classic and that's still out there. Some customers are still using that and we have to keep that going. But the new releases the Sitara SDK releases in last fall and the one coming up for this quarter they do a release every quarter those are now re-based on top of the Yocto baseline. You can see this if you go to the Yocto project there's a meta-TI layer which is all the TI support and then there's a meta-arago which adds the specific mix-ins that they add for the AM SDK. So we have meta-TI on the Arago project we also mirror it up to the Yocto projects Git server. So you can do Yocto project and take Pocky and meta-TI and that combination should work or you could build it just the way TI builds it for their SDKs using meta-TI and meta-arago. So the idea is that we give you the choice of whichever way you want to do it. Definitely start with the meta-TI I would start with meta-arago see what it does I would just try and both out and see which works better for you. If your use case is more aligned to what the AM SDK is doing you may find some starters in the meta-arago that may be useful to you but it's optional. The hardware support is in meta-TI. Thanks Bill. Why do you use the name Arago? I'll have to ask you. I'll buy you a beer if I know what the story is. Alright, other questions? Yeah? Yes? Yeah. The beautiful thing here by the way is if we can get everybody to sort of use the same sort of approach to embedded Linux it really makes the whole ecosystem much more efficiently so people don't have to do a bunch of porting work or whatever. Freescale we've been working and very grateful to Matthew McClintock did I get the name right? Freescale and he's been maintaining that work and so it'd be great I think the Linux Foundation do talk to them periodically about joining the advisory board so I think they just joined Linux Foundation recently, yeah? I think it was the last I'd heard so hopefully at some point they'll do that but yeah that's kind of the idea, the chip vendors basically supporting this general direction supporting the Octo project producing BSPs so they don't have to produce a separate sort of silicon Linux. Any other questions? They're doing it for both PowerPC and their ARM parts they're maintaining they're they're maintaining their SDKs Metadata Okay, other questions? Yes, please Yeah Right Yeah Yeah Yeah, so let me give you kind of a so the model is I thought I understood your question then you added another piece which I thought was interesting So let me see if I can answer or probably do a bad job The general idea is that doing BitBake requires a reasonably sized system and also do you really want to have all the application developers rebuilding Linux? Well you can't, no, yeah Things are really set up so that with that SDK you have all the cross tools so the cross GCC and cross libraries and all the rest of that are all set up cross debuggers, etc. Plus assist root for your target device so that's how that thing is set up so that typically you could create your application What you're, I think talking about is now I want to reincorporate that application back into the image that's being created That is that's really that's really a good question for the automation specifically for that, do we? So that's a part of the workflow that would need to get filled in by how you want to manage it Is it? Okay, yeah Well, yeah because it's a little daunting sometimes Yeah What he said was this is one of the part of what we'd like to do with the Webhob project is work on more of these workflow things and so we'd love to get your input and we'd love to talk to you maybe and see if I can get more I think I understand what it is you're saying and it's something in my mind that's been sort of missing as well Now there are other more commercial products for example that do have tools Hey guys, there's seats up here if you want to come on down why don't you come on down We'd love to have you down here so you don't have to stand in the back I know it's more fun to be Thank you Tracy I'd really like to talk to you more to see what we can do to again philosophically we've tried not to be too rigid in terms of how we define the workflow but that's probably an example of something we could do a few more things in Yeah, so how would they do that? That would probably be with that For sure joining the Yachto project mailing list would be really good There is a Webhob mailing list so that's another place probably good to join Excellent, yeah, so we have a designer who's working on the team actually one of those user interface experts who's actually looking for help from people who can give her feedback on that stuff so that would be really good, yes sir Yeah, I mean the way to think of it one of the things that's really powerful about this is that because we create a package feed and then create the images from the package feed we actually have the packaging, the package tools available if you're using RPM we were using zipper and now we're using smart is what we're moving to, the smart updater is just the DEB tools basically for DEB packaging, so yeah, that's actually pretty powerful from that sort of development standpoint if I'm doing development here, I don't have a package there, I can have it populated in my repository and then just populate and just install it from there Once the system's been installed Yes Yeah Oh, you're saying opening that thing up like mounting on a file system then sticking another file in and then unmounting that sort of thing, did I just ask and answer my question? Doesn't work that way in the moment? Well so yeah, let's talk more about what you were thinking about I mean generally speaking the development plan the development model is that you would install that image on a device and use the package management tools to update the packages while you're doing development if you just had the image sitting there and you wanted to jam a package into that image, I think you'd just have to pretty much, you could just mount it, can't you? You could just mount the file system and just add it so that's fairly simple or just rebuild the image, yeah because that's pretty much the last step of what happens at BitBag Okay, other questions? I think Tracy, you wanted to just have me to see if I can put the website up, right? No Go for it Is this right? Sure Can you hear me? Does that help? Should I talk even louder so that you wake up? Everyone's awake, actually So my name's Tracy Urway, I actually work for Intel but I'm also on the advocacy subgroup of the Octo project and because I didn't pay attention to anything that Dave said Forgive me I know he must have talked about the governance model and I know he talked about the compliance program and whatnot but really to me when I look at this project and being from when I say advocacy I'm talking about marketing and so I want to talk to you about marketing the project before we go any further because this is a room full of people who are in an advanced training session and so I know the project's actually getting used somewhere I started off in embedded systems development and I went to marketing because you got to dress better basically and that was important to me so I take it very seriously I'm just kidding, you guys have no sense of humor I take it very seriously and when I talk about marketing the Octo project I'm not talking, you know, you don't have to cry at the hallmark commercials or whatever it's not that serious but the more people that know about the Octo project and know what you're doing with it the more people are going to be interested in using it because it's seeming to be very worthwhile and more and more people are starting to come to the training sessions and ask questions and be on the email list and whatever so we actually I don't know if you guys have seen the booth yet we have this temporary booth that anyone who's at a conference and wants to represent the Octo project you can grab the booth and take it with you and do that, it doesn't matter who you work for if you're talking about the Octo project and contributing to the Octo project and serious about it you can use the assets from the project itself we have a new website that we managed to put together and if you look at the website one of the first things that it's that it does differently now than it used to do is it has this section called the ecosystem and if you look in the navigation and the ecosystem is supposed to be about what you guys do it's your projects like Mr. Ridge Run we would want to talk about you on the Octo project website seriously Todd and all you guys I don't even know where you work, let's see oh that's right, you're from the University of Costa Rica and we're trying to figure out how we can do some educational stuff with Costa Rica access communication do we have anything on our website about you not yet not yet, good answer see that's what you're supposed to say not yet and then you look at my badge you say not yet Tracy we can't wait to contact you and talk to you about this and I'm serious because it means a lot more to the entire industry to know that people who work for really well run interesting cool product kinds of companies are interested in the Octo project processor it doesn't matter what you know commercial operating system you might be using it doesn't matter what kind of systems at all or it doesn't even matter what your product is you don't even have to have a product you can just have a POC you can be doing R&D it would be really cool to hear about it in some way shape or form so I'm not sure you know at the very least right now being part of the compatibility compliance program having a product that's compatible or being a participant is at least a first step or one step but we're going to start coming up with other mechanisms so that you can tell us about what it is that you're doing if you want to what Dave oh god not that one sorry that's really all I have to say that was sort of timing us that's about as much marketing as anyone can handle at ELC so I'm done Dave your turn again this is when I expect a lot of applause because I don't know how many of you have made the effort