 Hello everyone. I'm Robert Call. I'm the lead developer of the LibreCMC project. I was the co-founder of the LibreWRT project. It's the project that essentially came before this LibreCMC. It was a fully free and very GNULINX distribution. It had some differing goals. I've worked for a few nonprofits that worked for providing free Libre education resources. One of those nonprofits worked to make a place for students to share their notes when they're done with classes and share them under a Creative Commons license. In my free time, I do advocate for the usage of free software both in my personal and in my professional career. I also break stuff for other people, sometimes for the better or worse. Before we get to talking about LibreCMC, we need to talk about LibreWRT. This is pretty much where it all started. Five of us at LibrePlanet 2010 got together and wanted to create a fully free embedded distribution for the focus of their own PDAs and music players. There's this fully free PDA device called the Beneno. Has anyone ever heard of this? Does it ring a bell? It's been awesome. It was essentially probably, I would say, one of the freest computers that we've had to date at this point. Considering that all the schematics are free, the CPU was free, it didn't need any microcode or initialization blobs and the like. We set out with LibreWRT to create a fully free distribution with the hopes of getting the Beneno RYF by the FSF. The FSF's RYF program hadn't existed as of yet, but there were internal talks about starting such a program and we wanted the Beneno to meet all those goals. So we needed a fully free operating system that didn't have any non-free blobs or any non-free packages, if you will. Sadly, I was limited on time, so I kind of had to walk away from the project in 2011. I also had some design issues that I wanted to fix, but a lot of the people using LibreWRT really didn't feel that was really necessary. They wanted to keep it mostly a clean open to VRT with the Linux Libre kernel and leave all most of the packages in. So what's LibreCMC? It stands for the Libre Concurrent Machine Cluster. The name at this point, I'll get to you in a minute. It doesn't really reflect what it does now, but it's a fork of OpenWRT, then lead, now OpenWRT again. Is anyone familiar with the OpenWRT forking situation? So I believe it was back in 2015. Seven of the OpenWRT developers weren't really happy with the way that the OpenWRT project was being managed. So many of these main contributors went off and forked it into the lead project. They forked it with the intent of making it a more community focused endeavor. They wanted to make anyone who is a contributor have voting rights, and they wanted to focus on certain things. One of the notable things that they did want to focus on was focusing on the IPv6 stack in OpenWRT. And then about, three months ago, four months ago, they finally re-merged into OpenWRT. It's essentially, they took lead and threw the OpenWRT branding on it, and now it's OpenWRT. LibreCMC uses the Linux Libre kernel. Has anyone heard of the Linux Libre kernel? So the idea behind the Linux Libre kernel and that effort is to remove all the non-free blobs and components from the Linux kernel. So we use that instead because we don't want to advertise non-free software, and we don't want to use non-free drivers because it's part of the FSS requirements for being a GNU-free software distribution guidelines. We remove targets which have a hard dependency on blobs. These targets might require a non-free driver, meaning the source code for the driver is available. We're depending on the OEM to what the chips that manufacture to build the driver for it. Or it requires a local firmware blob which, again, the community doesn't have the sources for it, or they're under a restrictive license. So we remove those. But we do leave in some targets which might have a soft dependency on these blobs, but still would function as intended, or might function in a limited fashion. So on some of our targets with the 802.11 AC stuff, we don't really have any drivers. However, the first generation of AC routers shipped with a removable mini PCIe or a double mini PCIe type card, which could be replaced. So those are where we make the exception. We don't officially announce support for those devices, but we do leave it in. So if people actually do want to use Liberty CMC with those devices, they actually can. We also don't include support for devices which require initialization blobs. So the Raspberry Pi is one example that people are familiar with. However, there has been progress being made in creating a fully free initialization blob for a free loadable... There has been work... Okay. So the Raspberry Pi requires a non-free initialization blob. There has been progress made in making a free software initialization blob as a drop-in replacement. So the Liberty CMC project, as itself, started in October of 2012. Its original goal was not to target routers or some of these devices, but I wanted to create essentially a drop-in component that would allow for distributed compilation of... Because at the time I really didn't have means to go buy expensive hardware for building Liberty WRT. I needed to use the hardware that I had just lying around, and this was an endeavor to do that. It failed because I just lacked the time not to mention dependency issues and other complications. There's a lot of... There's a lot of drop-in replacements that already do this, but I wanted something that was a little bit leaner, and that endeavor fell off the face of the earth at this point. So the Liberty CMC name doesn't really reflect what its initial goal was. I was approached in 2013 by an OEM to... They wanted a fully free embedded distribution because they wanted to be part of the SRYF program. I couldn't think of a better name, so Liberty CMC stuck, and we created a maintained embedded distribution. Liberty WRT had kind of been erratic with releases, sometimes happening every six months, sometimes a year, so we needed something that was a little bit more up to date. So the Liberty CMC project right now does target routers and NAS devices at this point in time. We release every three months, six to three months, and then usually we'll of course have some security updates depending on the severity of the security update. So things that allow us to allow someone outside of the device running stock be able to get root or access to the router, that would be really bad. So we always patch those usually within 24 to 48 hours of being made aware of that. Right now we also want to try to start targeting having a 10-year lifespan for the distribution for long-term LPS releases and possibly longer. The problem that we have in the embedded space right now is the fact that we don't really have long-term support in terms of being able to build it 10 years from now, which can be a huge problem. So why do all of this work right now? We have OpenWRT, we have a whole bunch of other projects, and we have a lot of stuff in this space, but some of it doesn't quite fit what we're trying to achieve. I'm going to add, I don't want to. So how many people in here, I'm sure a lot of people in here are working in the embedded space, right, in some shape or form, right? Raise your hand if you do actually, okay. So a lot of times, many of these embedded devices, they run non-free software or they're closed in some fashion. They restrict users' freedoms in some ways or they're not compliant with the sources. So many of the solutions that exist for providing an open-source or free distributions for these devices, some of them provide blobs or non-free packages, or packages which are encumbered by patent issues or the like that make them non-free. Many of these devices tend to be black boxes, which is a huge problem. Has anyone recently bought a car within the last two or three years? Okay. How many of them included those infotainment systems? Okay. How many of them have stopped working because of a forced update? So has anyone heard recently, is anyone familiar with Fiat Chrysler and their UConnect consoles? So recently they just force-pushed an update which causes their center console unit to reboot every 40 seconds. So we get this with no mechanism to revert back, which of course, if you're going to work with embedded devices and you're going to be doing updates, you might want to have some sort of mechanism for reverting back. So a lot of these people are going to have to take their vehicles in and they're non-free. So anyone in the community can't go and actually fix these problems. The other problem we have in the embedded world is forced obsolescence. Who here has smart light bulbs? Anyone? How many of you have used the Philips Hue light bulbs? So their first generation light bulbs, they forced an update to brick these devices so they just stopped working. And this is a huge problem. And it's not just this, just smart light bulbs. It's a lot of these smart devices where companies can see, well, they're not going to maintain anymore so they're just going to make it dead, which I guess that is one way to go about your security model is you just don't want people to use it anymore once it goes and stops working. You don't have to worry about updates anymore. But the problem is that the user, in a lot of cases, doesn't have control over this. And a lot of these devices are running free software, but you're kept from that. They don't distribute, they don't comply with the licenses. Or they do a lot of design. They design it in such a way that it makes it really, really difficult for you to go and run your own software on these devices. Another mechanism is a secure boot, arm for instance. So some of these devices have signed firmware and they have signature checking which the keys are fused into the CPU die at the factory. So you yourself can't actually go and change these keys. Without a lot of work and a lot of times it's actually just impossible. Sometimes manufacturers love to cut serial lines or make them really, really difficult to break out. So if you wanted to at all start playing around with it, you can. A lot of times if you change the software on the device, the vendor might say, okay, you can put whatever software you want on it. However, when you unlock it, they might make the boot loader show a scary screen saying this device may cause death if it's unlocked essentially. Usually it says that they're not responsible for injuries caused as a result of changing the software on these devices. But for a lot of people that probably would be scary, they go pretty far with that one. This is in the case if, does anyone have Motorola phones? Has anyone seen the scary message? I've been wanting to change that. I just haven't had the time to actually go forward with doing that. And then some devices they'll go and they'll just brick. If it detects that unauthorized software is being used, they might actually brick it. This was made famous with the release of the first Nintendo 3DS. I don't know, I don't get their naming scheme at this point, but it was the first Nintendo 3DS system that Nintendo released back in 2010. The SSF did a campaign about this. And on the box of this Nintendo 3DS, the first gen, it says that if you running authorized software on this device may result in it being non-functional. There are many options in this space in terms of being freer than what normally would ship on a lot of devices that these projects talk about. Many of these projects listed are great. They just are not great for the focus of some individuals. OpenWRT, it does have some non-free packages, some non-free drivers. The driver situation has gotten better. There are more free software drivers, but some of these chipsets require loadable firmware blobs. And some of these can be really small, like maybe a few dozen kilobytes or whatever. Or it might be that sometimes it's half a meg of stuff that has to be loaded to some of these chipsets. They also include some patent encumbered packages, which have a gray area. And those can cause some issues. And some blobs have restrictions where you can't reverse engineer these blobs. It violates the license that the firmware blob is under. Also, they sometimes have restrictions on how they can be distributed. So with anyone here running any like NVIDIA cards back in the early to mid-2000s to late-2000s, does anyone remember the restriction on NVIDIA's distribution of their firmware blobs, their loadable blobs? So it's not just graphics cards, but there are a lot of devices which require these types of blobs. Has anyone here heard of DDWRT? I know it's very, very popular. And it does provide lots of functionality. However, it is a little bit restrictive. Some features on certain platforms do require activation. I can fully sympathize with them. It's their business model. But some of the sources that they provide don't always build, or sometimes they build with some tinkering if you know which path to go down, or just not as a whole. And I can understand sometimes it doesn't because it requires maybe a specific distribution, which this is really a huge problem, especially if you're wanting to build it two, five, or ten years down the road. Sometimes it's not really practical to do that. Sometimes, though, you might need it because maybe it supported a particular platform, but newer versions of what available is not there. So you might want to look down and see what exactly they did to get support working. Opened up bedding in Yachto. I thought they're really, really great platforms. I mean, they do distribute the Vanilla Lex kernel, which the FFF does have a problem with. But the other thing is, in my view, for what it provides, it's a great tool, and it makes it really easy to build for embedded platforms. It's just a little bit too bloated for our focus. A bunch of cores available. Is anyone using it in anything right now? It's essentially they're targeting for embedded in Internet of Thing devices and sometimes some networking appliances. This has changed a little bit. I probably shouldn't have done that. But a bunch of cores a little bit bigger than our target platform at this point. We definitely, our target devices are, half of our devices that we support, we only have four megaflash and 16 to 32 megs of RAM. So that's a huge problem and a lot of canonical and a bunch who have been working to reduce some of these footprint issues. But this is the way they're going. For what a bunch of core provides, it is definitely a great way to ensure that you can easily roll back images. There's like a, last time I looked, there was a one gigabyte fallback for each system running on it. So you essentially have two installs, one to fall back if in case something breaks. No. What? No? You don't want this to fall. So recommendation, if you can't make an 8-dig, make it like 25 to 30 percent available. Wait. If it's the only thing. Wait. Wait. Wait. No one's speaking in here, right? Okay, well. Did I come in? Okay, I'm still speaking. I just. Yep. Okay. Okay, testing. Okay. I think we're good again. I mean, so, no, so again, within the last seven months, I have not followed Ubuntu Core. I will admit that they are getting better in terms of flow. Wait. Okay, well. Okay. I think I'll continue now. So they are making, they are making, they are trying to work on. And just to go, keep going along with what Memories is, there's also this other setting called Workmask. This is where people usually call PostgreSQL a memory. You can see it actually has a very, very small value to it. Usually, you know, they try to call from A to B, sending it to between two and five, and it usually exists from the point of the test. The more memory you have, you can start setting it higher. Basically, what this does is every. Testing. Testing. Every time it does like a source, or any kind of work that it has to do, and at that time, it's a memory source, that's what this setting is for. So, and it's not just, it won't just. Wait, wouldn't it be easier to. Okay, I don't know. Huh? I don't know if they want anyone changing that because. But I think the large group organizing needs to do that. I mean, I just. That memory is additional memory. So, not quite. If you have your next connection set really, really high, and we're using all of them. Also, it's in that room, okay. Yeah, they're going to have how much information. Yeah, they're going to have to change the frequency it's not going to. I don't want to get too much more into this part of it. I'll leave a recommendation at the link. I'll probably answer a lot of the questions that are right in your head right now about these settings. So I'm just going to move on to that here and see how that can help you out later. Yep, here you go. No problem. I don't have the handheld one. Testing. Am I good to go? Okay, awesome. Okay, so again my information on a bunch of core might be out of date. Again, they are doing things to rain in the bloat. However, we want to make our core a lot smaller than with their goals. I mean we'll talk about that later. There are also embedded WM, but again, it's a little bit too large to be running on routers. If you're looking for package management, well, kind of all bets are off at that point considering again, most of our targets are only to have 4 megs of flash and might only have 16 to 32 megs of RAM. And we definitely don't want to make those targets obsolete. We should definitely be able to still provide a router distribution that will fit in that space given with the minimal amount of features that people are looking for. So again, package management comes at a cost. It does add just a little bit of overhead in terms of resources and a lot of these embedded devices. It's not really practical to have full package management support. But we are trying to – this is one of the areas that we do want to work on as the Liberty CMC project. Many people complain that manufacturers don't update their platforms often enough, but the real problem is a lot of these manufacturers don't really focus much on – really focus on their security model. You should be able to have these devices working for a long period of time and prepare to be able to mitigate for some security issues that might pop up. A properly configured device definitely goes a really long way in terms of preventing a lot of holes that might pop up. Not everything should need to be connected to the Internet. I mean how many people in here are compelled to own a smart fridge or smart device or smart light bulbs? I mean it's a convenience thing, but not – I personally don't want all my light bulbs. I mean I can understand having a separate network completely isolated, but a lot of these people are connecting them directly to the Internet in some way or fashion and so it's pretty easy to turn on someone's light or possibly do something even more dangerous. I mean there's now toaster ovens that now run Android. Has anyone seen one of these? I mean there is definitely a market. These things definitely go a long way and they do make our lives more convenient, but we should definitely think about what networks they're being connected to. So also a lot of these devices should fail gracefully. Has anyone seen message boards or signs that have a Windows blue screen of death or a kernel panic? Yep. And a lot of times that really shouldn't be happening. It's just showing information. Sometimes it's because the device overheats or sometimes it's because some resource isn't available or there's some other weird bug. A lot of these devices really need – if they're being used in critical pieces I would say as a critical device, but they should definitely fall back gracefully. They shouldn't have to – the manufacturer should prepare the device in the event that some component of it will fail and have a plan for dealing with that. So these are all of the things that I've talked about at this point that are wrong with the embedded space. We would like to address some of these issues with using LibreCMC as a platform for moving that work forward. So I'm going to talk more about LibreCMC but I get a lot of people saying, well, LibreCMC doesn't support X, Y, and Z, so I'm not going to use it. Okay, well, LibreCMC doesn't support everything in the sun. Given our constraints and the fact that we want to be a fully-free software distribution, we can't support everything under the sun because of that. We can't support some non-free packages or device drivers. And there are people out there that really do care about that and want that focus. So that's what the LibreCMC project is here to do. We also want to focus more on security and bloat as well. There are more platforms that we would love to target, but we need to get our base down to in the reach ballpark of 2 megs of flash and 8 megs of – using only 8 megs of RAM. This may not be practical today given what people really want in their devices, but we're certainly going to try and it might involve a lot of work. We're not competing with projects. We are standing on our own right for these reasons that I've laid out. So if it works, great. If it doesn't, well, maybe it might be – we might be able to make it work in the future and maybe a manufacturer might see, oh, there might be some benefit in releasing the firmware blobs for a particular chip set. If they do that, that's great. We can then support that device, but at this point in time, we can't. So right now, the LibreCMC project is essentially two projects. One is focused at consumers and people who actually want to use this on their routers and other devices. And the other is research, which of course is unstable and some of it doesn't see the light, some of it does. But our consumer-facing project helps fund the research side of the project. So we work with a few different OEMs. We encourage them to make a small donation if they're going to ship with LibreCMC. We encourage them to make a small donation for the hosting space, possibly, of custom images and source code distribution disks and the preparation of those. So one of the – what we push OEMs to do that are shipping our devices, devices with LibreCMC, is we want them to provide a source code disk with the device and it must build on a recent GNULEx distribution. We work with them to prepare these disks to make sure that they build. All the sources are available in the respective image. And that's pretty much it. And that's a huge thing because a lot of these devices running GNULEx or Linux, the Linux kernel, they don't provide source code disks. And half the time, you might be able to write them and they're you're lucky if they're going to respond. And then sometimes if they do respond, they might provide you a disk, but what you get isn't always the source code that they distributed. And a lot of companies just feel, oh, they can just – they don't have to worry about it because the litigation aspect of a lot of the licenses is pretty – well, the enforcement is costly and there's not enough people doing enforcement in that area. Also, it's a nice thing to give your customers a source code disk that actually builds an image that can be flashed on it, considering that they can then expand the capabilities of the device later, whether it be now when the device releases or maybe five years from now when the device is on the second-hand market. A lot of these – many people don't realize that not everyone has the resources to go buy a brand new router every two years or something ridiculous like that. And in the case of Liberty CMC, sometimes some research, some stuff that we do doesn't always pan out. We just move on. It's expensive work and it does take a lot of effort. So that's a great question. Thanks for bringing that up. So a lot of work has gone into OpenWRT and LEED and OpenWRT again for the idea of reproducible builds. So some aspects of Liberty CMC are – some aspects and packages are reproducible, some not so much. Some kernel stuff – a lot of the kernel stuff is reproducible on some platforms but not all platforms. LEED, I think it might have gone in the back corner but I'm not sure what the progress they've made lately. But again, Liberty CMC, since we're basing it on LEED Stable 1701, we do benefit from some of those, the stuff that LEED does. Did I answer your question? Wait, oh, what? No. What's your build like? What? What's your build like? So we're going to get to that in a second. It's – I didn't – okay. Hold the questions for a minute as we're still going to move along here, I guess. Where is it? So where is it? Thank you. So a lot of our focus, again, in terms of research, is in to blow our build system. Right now it's currently using – we're pretty much just a fork of LEED, lengthly recurrent or removed. So we're using essentially modified version of build route, to put it simply. We'd look into – we want – what we would like to focus on is to have a build system that can build on systems for that 10-year span. And the reason that's difficult is because of dependency issues. So a newer version of certain components might break compatibility down the road. So that's a huge problem, especially in terms of build systems for embedded devices. Build route does a really great job at this – reducing the breakage, but it's still quite – it still does it probably once every two to four years. So if I take a version of OpenWRT or any arbitrary version of OpenWRT or LibreCMC, and I want to build it four years from now, there's a large chance that some of the things will break. The other problem is some packages might drop off the face of the earth. So if you don't actually have a copy of that package, then it might fail. The link is dead. So we want to reduce all those things. Anytime we have a dependency, we always make sure all those dependencies are available for each and every version of LibreCMC. We started doing this early, and we plan on keeping all those packages for long spans of time as long as the LibreCMC project is around. It's something that we need to address, I guess, in the free software world where projects don't – projects – some projects disappear. Sometimes they're hosting changes. Does anyone remember Getorius at all? Anyone? Anyone you actually use Getorius? Anyone remember the breakage – some of the breakage – oh wait, Getorius and Google Code. Both of those were depreciated, and there's a lot of projects that were dependent on those platforms for hosting. And when those went away, a lot of the links broke. Google Code, they did keep some of the links on for quite a while. I think they're getting about to the point in time where they're going to start making them completely dead. But that's a huge change, and a lot of times, if you have this old version of the project, you then have to go find where they're hosting the code now, and they might not even have that old version of the package. And this is an issue that we need to address. And that's what I would like to address with LibreCMC, not just by us hosting some of those older packages, but also coming up with ideas to better manage these dependencies. 15-year extended long-term support is probably going to sound ridiculous. It probably is ridiculous in terms of effort needed to actually make that happen. It requires probably giving up a lot of – shaving off a lot of different dependencies of a build route, and a lot of the tools that meet packages depend upon for building. But it might be worth it. It might not be. That's probably going to be up to me and the community to decide on that. It might not be a great option. So, I mean, right now we're targeting routers and controllers, and PDAs are out of fashion at this point. Well, they were kind of out of fashion in 2010, but I still like the idea of having a small organizer-like device that I could control all the software on, and communication applications. We would like to get every CMC some of the extended packages. We'd like to get support ready for some federated and self-hosted services, like on cloud, and like the new social, or pump.io. Does anyone use – or diaspora, does anyone use any of those? Okay. So, we would like to make it so that we have a nice lean core that you can install some of – or we actually package up some of these things, and make them available to people to use. Because right now, a lot of these services are really, really difficult to install and deploy, especially for people who have no background in GNU-Linux or the like. So, we'd like to be able to make it so you can just download this image and maybe answer a few questions, and it would configure it for you. But this is a long way down the road. I know there's other projects that do focus on this, like the English for the Freedom Box project. But they're targeting Raspberry Pi, and they're using embedded Debian, but we kind of don't want to go down that road. So, where is it? So, our first area is research design. We want to not just limit ourselves to the Linux kernel. There are other Linux kernel variations that we could possibly use. Have anyone heard of UC Linux? So, those do run on some even more limited devices. Again, in some areas, I don't think that this is still the right route to go. I could be wrong on that. But any other paradigm is going to be really expensive in terms of research. There's a lot of cool projects going on, and we'd like to probably take some of those pieces and run with them if resources allow for it. We already talked about dependencies. So, the build system. Again, we do use, essentially, it's build route. It's modified by openNVRT, and that's pretty much what we're sticking with. We're sticking with everything that's based around the fact that we use build route. Sorry about that. Is there any way? So, yeah, in terms of bloat, though, one of the recommendations from one of the, I'm not going to say his name, but one of the recommendations from one of the openNVRT developers went to the most IPv6 stack. So, one of the problems we have in our routers is we use the Lucie Web UI. However, it doesn't really fit well if you want SSL and other flash plus have a full IPv6 stack. Sadly, right now, we're going to removing package management and SSL support to get Lucie running on some of these devices while we've been typing. So, we kind of had to weigh those choices, but we really don't want to have these. We really shouldn't have to make those hard decisions to stay back to bite us. So, I mean, it is one solution to the problem, but again, a lot of people might not have an IPv4 connection provided to them, rather than ISPs, so they have to use, is it six, no, four to six, or six, and then a few methods of the scope of the talk, sorry. So, again, Liberty seems to be not for everyone, but if you care about software freedom and pushing that idea forward in the embedded space, that's what we're here for. We want to make long-term support much easier and guaranteed. You should be able to take the sources that we provide you now and build them hopefully five and 10 years from now if all the dependencies, as long as we make sure that the dependencies are cut down in such a way that they'll be guaranteed to be supported that far down the road. That also helps in terms of compliance. So, a lot of times, has anyone actually got requested sources and then they give you build instructions that are very vague? And at the end, it says you need Fedora Core 3 or something like that. Has anyone run into that? Yeah, so, a lot of times, you might not be able to find that version of Fedora Core 3. Luckily, we have the Internet Archive, but years ago, there have been versions that I just you couldn't find anywhere. They weren't uploaded yet. You didn't get a hold of the right person, so you're just out of luck. You couldn't build it. And I've actually run into that recently because I couldn't get to build on any modern system and I was hoping it would build on this particular version of Fedora, but I couldn't find it. So, we are open to incorporating any new features as long as they are free software and they don't add too much load or additional dependencies that are required. I guess I'm going to leave it up to Q&A. Does anyone have any questions or comments? There's a lot of wisdom in your presentation because most embedded systems, I have systems that are still there and still haven't been broken. So I ask you, do you statically link the kernel and drop off any drivers that you don't need for a particularly hard implementation? Given the routers that we build for it, that could be done in a better fashion. On our AR71XX targets, I don't think that's the case there. I mean, everything else is a module, but that adds more load to these images. More static linking could possibly be done, but we could probably modify it slightly so that we could do that. That would probably save a lot of space. It's just a matter of time constraints, so just maintaining what we have now does take some effort in terms of rebranding, making sure links with kernel work. Sometimes some patches, there are conflicts, so we have to do other. We have to patch those out or rewrite certain patches to actually make the thing built. Hopefully down the road, we can approach load from that perspective, but I don't, off the top of my head, we could be doing that better. That's a great point. Any other questions? I have a comment and a question. The comment is how very hard to justify making the very small, which shouldn't be that hard to justify, because there are platforms that are getting smaller and smaller as we're looking at something called PocketQ, which is satellite, and it's back this big. So the thing is that no matter how small you make it, somebody's going to come up with a smaller device. And where that goes is that, remember you mentioned Yuclenux or Yuclenux or whatever? I think that the point behind that is it doesn't require an MMU. So it might work on something like an M-Series arm machine. There are really, really small things typically around M-Series arms. Do you require an MMU to run? Sadly, at this point, yes, we do require that. I don't think there are any platforms that don't require one that's open to BRT support. I could be wrong on that one. We could possibly do that. It'd just be a problem matter of using Yuclenux to run out, but I haven't built it in quite a while, so I don't know what it can fit in is the real problem. The problem with this is time, because all this stuff does take time to play with and actually see how well that would pan out. The thing is we are getting more and more of these resources in this space. The problem, though, is those are not guaranteed. Has anyone looked at RAM prices lately? They recently, over the last year or so or two years, they've gone through the roof. So those types of fluctuations can happen, and what the manufacturer decides to use might change, and what the manufacturer has the option to use. So many projects don't really see this as to shave off every single 10 kilobits here, 10 kilobytes here, it's kilobytes, sorry. Some people don't see the justification of it, but it can have real profound effects when someone's going to try to build some of these devices. Is there any more questions? Yes, so that does come... Wait, so can I address that, or do you have more? Yes, I do realize that that is a concern in this space. A lot of these blogs are getting pretty huge, and as anyone familiar with the last year, there was a huge security vulnerability with some Broadcom chipsets that revolved around some of these blogs, and we as a community couldn't fix them. We'd have to wait on Broadcom to actually go and push out a new update. I understand that we're not going to be... RiverCMC is not going to be popular with a lot of people for that particular reason. I didn't start this project because to take the easy way out, some of us do care about software free, and we want to be able to see what the software on our embedded devices is doing and be able to fix issues that come up. Lou, do you have any more support than AR-71S? Okay, so we do support some other targets, not officially, though, for some reason. We do have some... We do support some of the all-winner boards that use the A20 SoC, the Beagle Bone Black is not officially supported. If anyone can answer this, I'm still having issues with the license around one of the initialization blogs. Not really a blob, I mean, the source is available for it, but it's under some Texas Instruments license, if anyone can clarify that. Okay, cool. Yes, but what about... I thought there was a component that you have to build dropping to get it to run on the Beagle Bone Black. I mean, so it uses Mainline Yubu, it uses Mainline Yubu, so... Mainline Yubu does have some initialization blogs, sometimes around memory initialization and some other CPU setup stuff. Okay. Because also the other people are on the other side of this wall doing that. Right, so I'm not an expert in this, we're not going to... For some things, if it looks good or clean, we can build a main image with it using only free software, then we'll support it, but we only want to enhance the support for things where we're guaranteed that all parts of the stack are free software. Can I ask a question? Yeah, we're still on questions. So I have the... Okay, thank you for supporting the project. That really does help. Yeah, it works great. I'm wondering though in the future, will we be able to run this as the newer hardware that's coming out? Run what exactly? Run Libre Team C on our version. So our bottleneck right now, we could. The problem is that again, Y802 OpenAC chip sets, there's no one right now that we know of that is releasing software versus for the loadable firmware. And there's a lot of things that we're actually restricted from doing because of that as well. In terms of making mesh networking slightly more difficult. And in terms of initial bugs, F10K had quite a few bugs initially. So our bottleneck right now is mostly blobs in that case. So that's the reason why we're not supporting any slightly newer targets. We also have been looking at possibly getting a more modular router out the door that we might be able to support faster, faster CPUs and things so we can do some cooler things and actually host some resources on some of these devices. But as of right now, I mean, if it's free software, we will be more than glad to support it. So the FCC guidance from last year so do I need to put a gap on things? So, yes, in some cases, there isn't, there's not really, so it only applies to five gigahertz devices and the approach that TP-Link made was not really the right way to go, but that's kind of what we feared initially that companies would do because they wanted, because the FCC required that you couldn't make the Wi-Fi chips that operate in an unapproved way. So TP-Link went throughout of just locking down all the firmware. You pretty much had the TFTP flash it. You couldn't flash it from the web UI for a lot. Oh, and they went further and cut the serial line so you have to solder two, four solder pads on the board to get a serial interface. So the serial was there. They just cut the line and put two solder, two pads there, four pads there. So, yeah. Hope? Oh, Eric's gonna, okay, so one of that, he might not go to Liberty Point. So there is someone else who did a lot of work around that whole thing. What's his name? Eric what? Yeah, Eric Schultz. He's given a few different talks which are online. I believe he talked actually last year about this very same thing. It hasn't affected us yet, but it could definitely affect us at some point. Actually, I would like to add one thing. So some vendors have actually gone the route of having, doing signature checking on the particular loadable firmware to get around that. But I mean, the only real way to do it with the F9K stuff is to just lock down the whole firmware to keep people from doing that. It's not really, we're really obsessed with F2C and just go that route. They really pushed that what we said wouldn't happen when TP went and did the exact same thing that we said would happen. Does that mean that... Can you speak up a little bit louder? Like, you know, break the router open. So the other thing is our targets do, we do try to focus on targets that allow you to flash an image through the web UI and we made the exception for some TP-link routers where you have to use TFTP boot but you did not actually have to open the router unless you needed to debug something that had failed. But they started locking it down. So in TP-link, it's not... It's kind of probably wrong to actually say it's a full lock down. It's more or less a restriction on the web UI that you would load the firmware to. So you could still TFTP flash it. You just had to name it to a certain string. So what you do is run your TFTP server and see what file name it requested and then rename the firmware you're trying to flash it to to that name and then it would magically flash it. It didn't do any signature checking on it. Yeah. But it's still more difficult for regular users because when you try to get regular people to use some of this stuff, it's a challenge especially in terms of the steps, the hopes that you have to go through. Is there any more comments or questions? Okay, I believe we're... We've got two minutes. Any more questions? Well, thanks. I'm glad that I was able to make it. My flight was... We luckily were able to bump our flight up otherwise we would have missed this because of the snowstorm. So thank you everyone.