 Guten Morgen, that's the extent of my German, and maybe I'll be doing it at the end. All right, so my name is Karim Jagwar, and in the next 50 or so minutes, what I'll try to do is convey what I've been able to find about Brillo and Weave, and do so in a very specific fashion, which is using the sources that they've released. As somebody asked me right before the presentation here is, how come you can actually talk about this, since all of their stuff about Brillo and Weave is still confidential? It's your part of the beta, and you've visited their website, you know that essentially they've got this, you know, please replicate this anywhere, it's like written in big red letters at the top. I haven't used any of that material at all, in fact, I deliberately shot away from it. So what I'm using really is the sources that they've released, which are on android.googlesource.com. All right, before I get started here, I just want to make sure I have a good feeling of who's in the room. So if you just raise your hand for the following questions, who's got any sort of android platform development experience, okay, a Linux kernel development experience, all right, who's signed up on the Brillo beta, okay, handful, all right, yeah, that's good enough for me. All right, so, yeah, computer, yeah, the slides will be up after the presentation, the kind of guy that finishes his slides 15 minutes before, wink, wink. So just a bit of background about myself, if you've never heard about me, I wrote the embedded Linux book for Riley about 13, 15 years ago. It's rumored to have been used to put Linux on the first Amazon Kindle, so that is something that's really cool. A couple years back, I wrote the embedded Android book for Riley, which has also been used for quite a variety of different cool products, unfortunately, most of which I can't tell you about. I've been involved in open source for about 20 some years, most widely known for having written the Linux Trace toolkit, which was one of the first tracing tools for the Linux kernel. Fortunately, somebody else has been doing a much better job at maintaining it since 2005 than I was, and they're actually here doing some talks as well. And I used to be heavily involved with Project Era, which as you probably know has somewhat been put on the ice. And that's pretty much it. The thing I want to highlight here is that despite my background and any books I might have written, I don't actually know everything. It is very likely that people in the room here might know more about some things that I do. And if that is the case, please feel free to go ahead and share whatever your experience is. In fact, I'm fairly easy going about these presentations. The more questions get asked during the talk, the more entertaining it is. So otherwise, I hope you're well caffeinated because this might be very boring. Okay, just a bit of background here. I mean, what gets me interested in Brillo and Weave? And you'll see it's a bit different. I mean, my view of Brillo and Weave is different than what, say, Google might be pitching about it, although I think they have a nice pitch. There are some things that I think are intrinsically interesting about Brillo and Weave beyond what Google wants to do with them necessarily. So first of all, let me just... Sorry? I thought somebody had a question. All right. Let me just give a bit of history here about what gets us into Brillo or Weave and whatever. Why is that interesting? First of all, what is Embedded Linux? So I would like to think that having written a 400-page book on the topic, I would know something about it. Unfortunately, Embedded Linux is not something that you can actually define very precisely. The best I can come up with is Embedded Linux being, say, a set of ad hoc recipes for creating customized Linux root file systems running on top of Linux kernel for specific purposes. Beyond that, really, there's no strict definition of what Embedded Linux is. It's a very broad term. Usually, however, when you are talking about Embedded Linux, there are some usual suspects. There's a busy box. You probably have Uboot in there. Obviously, likely you have a Linux kernel and a few other things such as that. But there is no formal definition of it. And beyond that, the one thing that's still to this date, to a certain extent, an irritant with Embedded Linux is that whenever you create an Embedded Linux system, you are defining the API of what that system is. You have to spec it out, and you have to find people that will know how to code for that thing, whatever those APIs and libraries that you choose from. So that's something that is a challenge. Another thing that had historically been a challenge is user interfaces. There's not been a standard user interface for Embedded Linux other than, say, Android when that came along. Now Android, interestingly, is a very custom use of Linux in an embedded setting. That being predominantly, obviously, mobile in the beginning, gradually other things than mobile, including, you know, obviously things like cars and other interesting niche applications with time. Some things Android kind of rewrote from scratch, and in the beginning that used to rub me the wrong way. For example, when I got into Android, I was like, oh, look, probably it's going to be, you know, got a busy box or whatever else, and then you get in there and it's got this thing, a bastard thing called Toolbox, and in the beginning, for those of you who used it, it used to really suck very bad. They've made it better over time, and now they outright replaced it with something called Toybox. But in that pattern, they've applied throughout the stack. They've gone out of their way to replace key things that were licensed, that were originally licensed under GPL or LGPL with things that were either BSD or a Papi licensed. In fact, if you go back to some of the very early presentations they've done about Android at Google IOs, I think about 2008, they had a presentation called the Anatomy on Android, and the gentleman in the talk essentially outright says it that, you know, they deliberately chose to replace things that they felt did not have the proper licenses, all right. So if you're coming from an embedded Linux background and you get into Android, one of the first things that kind of surprises a bit is the extent to which they've replaced things that are common in embedded Linux. The difference between embedded Linux and Android is, embedded Linux was an organic thing. You know, nobody set out day one saying, we're going to create embedded Linux. It's more like, you know, some people are using DOS, embedded DOS in the mid-90s in their embedded systems, and they started looking at this Linux thing for their desktops and eventually they're like, wait a second, this thing runs in an X86, why can't I just run this on my embedded system? People start piecing things together. At a certain point you need a bootloader, somebody's got a shoe boot, you need a C-Library, they're at UC-Lib C and so on and so forth. Android on the other hand was a very deliberate effort on the part of a single corporation to create an embedded Linux distribution with a very specific purpose in mind. And what they've been able to accomplish with that is something that we've never had with Linux, which is, or embedded Linux, is a standard API that is known by a lot of people. We can complain a lot about many things in Android, but one thing they got right is an API that is standard across all devices. What else can I say about this? So yeah, they've introduced a few different things, you know, fast boot and so on and so forth. All right. This I just picked up off of Google Plus. You can see that essentially in terms of market share, Android has eaten everything. One of the people that responded back to my post on Google Plus was saying, oh, no wonder Apple is trying to go after cars because they've exhausted their ramp up on the phone side of things. That's it. That's it. It's done. And this is very impressive because we've been talking about Linux coming to the desktop for the past 20 or so years, and it never has, and it probably never will because the growth factor for desktops is flattened, but in terms of mobile, it has definitely eaten everything out. And this is interesting because from the embedded perspective, there's a lot to be said about using a standard platform that is widely deployed to users for embedded purposes. Such was the case with DOS, and such did, you know, at least Microsoft tried to push it with Windows and T, and famously Mark Andreessen had said that running Windows on your pacemaker was a self-replicating market. So but Android today essentially being deployed on so many devices makes it an interesting starting point for embedded uses. And so along the way, say in 2012, 2011, I had a customer approach me and say, hey, we'd like to run Android on headless systems. And at first I kind of giggle, I said, you've got to be kidding me. Why? Just use Linux. I mean, if you don't want the UI, just go ahead and grab that thing that's called Linux, which is what's underneath Android anyway. And they made two important points. The first one was the fact that they had multiple devices, multiple product lines, some of which had user interfaces, some of which did not. And they did not want to have to maintain, you know, multiple operating systems. I thought that made sense. I mean, that makes that, from a business perspective, that is a valid point, right? You don't want to maintain separate stacks altogether. The other point they made was that if they were using Android, they can get any Joe app developer to code for their embedded system, right? And that is a lot of value, right? Because you don't have to find somebody that has specific, you know, knowledge on an embedded, they just have to know how to write apps. So at ELC, I believe 2012, I had done a presentation on how to take Android and essentially strip the user interface off of it and run it straight on whatever device that you got. And when I presented that back then, people laughed it off. It's like, you've got to be kidding, Karim, nobody wants to do this. And interestingly enough, I was asked to do the same presentation six months later at Lenovo Connect Copenhagen. And then, as I was presenting, somebody raised his hand and asked, hey, have you checked out the RO dock and figured out headless flag? I'm like, I don't know. What is that? When did this appear? And so in the interim between my presentation and that other conference, Google had put out the Nexus Q, which was this media box. And in the release that came out, the Android release that came out with that, they had a flag that actually turned the thing headless. And that was kind of interesting. I don't know if there was any causality there, but it was kind of funny that they were interested in that, which gets me to Brillo. So Brillo's actually deliberate effort on the part of Google to actually take the success of Android and actually turn it into an embedded Linux distribution. Obviously the goal they have is the Internet of Things thing, which is let's put this everywhere and let's collect data and let's facilitate data collection and the device enablement and all this cloud stuff. I'm coming to this from the other perspective, which is I don't care about your cloud thing, but hey, you've got this operating system that's based on Android, leverages a lot of things from Android and runs on my embedded system. That's something I like. And then I want to cherry pick what's of interest to me, all right? So it was announced at IO 2015 and as I was attending the keynote, I was like, whoa, wait a second, picture, picture, picture. What are those diagrams? And they have references to how and stuff like that. But they hadn't released any code yet. Later that year, about in the fall or something like that, they made the first code drop. Whoever played with that, the code drop they made at the fall of 2015? Okay, well, I guess I'm the only one. Anyway, so I grabbed this piece of code and I started digging into it. It's like, okay, what is this? I mean, what are they trying to do here? How does this work? How's this different from Android? And what I discovered is that at least at that snapshot in time, my feeling was that Brillo was this bastard child of Android and Chrome OS because it was using a lot of things from Android, but it was mostly built with Gen2 things as well. So and it was based on D-Bus. Most of the communication was D-Bus based among all the pieces of the system. Nowadays they've actually moved away from that. So today they actually are using Binder as I'll show you a bit later. A lot of the glue in there is based on Binder. And kind of like as I was saying, the talk is based on the analysis of the sources. So I don't know what they're saying, their documentation online when you register, when you're on the beta. But everything that I've got here I've essentially deduced from looking at the sources. So what's interesting is that you can actually get the sources off of essentially android.googlesource.com, which is the same location where they're hosting the AOSP, AOSP being the Android open source project. For those of you who might not be familiar with the term. And most of the directories or the repositories that they need for Brillo are common to Android as well. So it's kind of like they have two manifest files pointing to similar directories except one of the manifest files has a lot fewer entries as I'll show you and some handful of additions that are custom to Brillo, which are not found inside of Android. All right, let's talk about architecture a bit. So okay, the color coding in my diagrams is gray stuff is in C. Yellow stuff is in Java, but has to do with the system. And then orange is regular applications, which you can't see on this diagram, because there aren't there yet. I'll show you that to you in a second. An embedded Linux system, again, per my earlier description, is fairly generic. So Linux kernel, C library, probably a busy box in some custom application, all right? There's nothing much more to say about that. If you're using Yachto or Buildroot or whatever else, you probably have also some usual suspects that go with that, will depend on whatever packaging system you're using. If you look at the architecture of Android, this is a bit what it looks like. So at the bottom most, you've got the Linux kernel, much like an embedded Linux system, but everything above that is custom, all right? So when you go to the native user space right here, you've got your Bionic, which is the C library. You've got the hardware abstraction layer, which is one of the key features of the architecture of Android. You've got some native daemons. You've got a user space shell, which is toy box. And then you've got the system services, which are the core of the operating system. And at the very top, you've got applications. And this stack, which is about seven or eight layers deep and is fairly hairy to deal with, is yet being deployed on hundreds of millions of devices. So it's a known quantity to a certain extent, all right, despite the challenges that go with this. And the idea is, if I want to take this and build a custom Linux distribution with it, that is, say, for a more general purpose than running user applications, what can I do with that? And that's really what Brillo is about. So moving a bit more into the stack, this is the binder functionality. Who's ever investigated binder to a certain extent? A few people, all right, yeah, ish, okay. Okay, binder is an IPC mechanism. I'm gonna, just wanna make sure everybody understands it a bit because it is fundamental to Android and these days it is also fundamental to Brillo. So think of sockets, but minus network connectivity and minus essentially the large file descriptors associated with those things in the kernel space. It's a very lightweight, so to speak, communication mechanism. And the idea there is you're serializing parameters and function called return values between two parties. So if I wanna talk to a service, I'm gonna call function foobar. Function foobar has an ID and I'm gonna find that services identifier. I'm gonna say I'm talking to function ID and here are the parameters of the function. It's gonna call that thing on my behalf, return me the return value and off I go. A binder driver doesn't need any hardware, so when it starts, it just initializes itself and stays dormant. First thing that talks to this thing is called a service manager, which is on the left-hand side there. It is kind of like a DNS service. You give it a string, it gives you a binder ID and use that binder ID to talk to the service that you're designating, all right? And just to illustrate this a bit more because we've found this, when we've worked with customers in the past, we found it's a really challenging for people to grasp what this thing is about. So let me just give you a demo here of a piece of software that we wrote that allows you to better visualize what's going on here. So what did I build this for? I think I built this for six. All right, let's go with that. Really, previous build, what did I build for? That's what I thought. So let's go with this, five, sorry. Okay, much better. Okay, so I'm just gonna let this guy restart. Let's do that. Sure, why not do that? And now he's gonna die or not. Maybe he shall, does that work? It does, all right. So we got this tool that we put on GitHub called Binder Explorer and it allows you to essentially just grab what is working on whatever state binder has and display it to you. So that, this, files, something else, this node. So we try to be trendy and we're using Node.js. All right, start this. Let's go with local host. All right, just give us a second. And in fact, it should do much better job than this. Let me just try one thing. Let's try that. Try this, he's gonna complain and that's okay. Now, oh, he's trying to get the icons. Let me reload. Okay, so what you're seeing on the periphery are the system services or in other words the Android operating system and what you're seeing in the middle is the applications or some binaries that are running in the system and the links that you see there are the binder communications, all right? So as you can see the binder bus, so to speak, even though they don't call it that way, is fairly busy, all right? And what we can do here is say for example I can go check out what is this, the phone application. So what is the, well actually that's the dialer, sorry. What is the dialer talking to, right? And you can see the system services that it's talking to and on the other side you can highlight any of the system services on the other side see which apps are talking to that, all right? So it's a kind of add a glance view of what binder does. Brillo uses binder and what I'll show you in a few minutes is a same snapshot but for what's going on with Brillo, all right? So let me go back to my slides up here somewhere. All right, so that's for binder. Now, as you can see in my diagram there is a lot of system services. If you wanna find out what system services you have you can just go in the shell. I'm gonna have to kill this, I'm sorry. So let's do this, service list. Those of you not familiar with it, I've got a hundred system services. They keep adding a handful every so often, all right? The system services are housed in different processes. There is a main system underscore server process that houses the bulk of the Java system services and then you've got C system services which are housed in separate processes. They seem to do a deliberate effort to put anything that is sensitive to human interaction into a C process instead of a Java system service. So anything that has to do with sensors or graphics or audio or multimedia seems to be deliberately put in C because a lag, right? They don't want the garbage collector to come in and stop your video as you're kind of like trying to listen to something on YouTube. All right, the other distinctive thing about Android is the hardware abstraction layer. So Android system services, which are kind of like the core of the operating system, don't know much about Slash Dev. In fact, they deliberately don't know anything about Slash Dev. Instead of that, they know something about HAL definitions, which are the APIs that the various system services need to actually talk to hardware. And so far as the system service finds, say, the lights HAL, it thinks it can talk to lights. However the HAL layer does its thing, it just looks for the HAL SO file and that's it. In Android, the HALs are far away from applications. They are inside system services processes, which are privileged, whereas apps can't actually talk to any of the hardware directly. They have to remotely call through Binder to the system service to actually access the hardware. In Brillo, this is kind of turned on its head and your application that you write opens the HAL module and talks to it directly. That's really one of the benefits of Brillo is that they're reusing or leveraging the existing code base of HALs that are out there, or the fact that SOC vendors know how to write HALs to actually allow people to code apps that use those HALs directly. So this is Debuss. Again, as I mentioned historically, Brillo was mostly based on Debuss. And for those of you who are not familiar with it, and this is something I grabbed from Debuss' documentation. So Debuss works by having a daemon that's running in the background. And whenever you've got two parties that want to talk to each other, they go through that daemon to actually get the message across. And in fact, if you followed the whole discussion about KDBuss and all that kind of stuff, the idea was to repatriate some of that stuff into the kernel to make it more efficient. So this is what Brillo is. We're just really getting rid of the entire stack above the native layer, right? And you better remember, what was it called again? Tiny Android from the 2.x days. So in the 2.x branch, you could actually build the AOSP and say, I want to build Tiny Android. And what that was really was just the bare bones file system with a few of the pieces in the native layer and that was it. And so Brillo is kind of like similar to that to a certain extent. It is really just a bare bones Android. But the interesting thing here is they've got the hauls in there that you can use to actually code IoT applications. Okay, weave on the other hand, and that's one thing, so coming to Brillo weave from an Android background myself, one of the things that confused me is all their discussion about Brillo and weave and I was like, what the heck's this and what the heck is that? So Brillo is the distribution, all right? It's that thing that you compile into an image and run on your device. Weave is a bunch of daemons that run on that along with some cloud services, all right? And the idea is that there's a weave daemon running on the device that listens for requests coming in from either a handset or a tablet or whatever directly, or comes from the cloud and possibly is triggered also by the phone or mobile device or whatever else. You don't have to use weave, all right? You can just go with Brillo and ignore weave completely. You don't have to run this daemon in fact at all. So let me give you the lay of the line. Let's go looking at the sources, see what is around and how's it different from Android. First of all, as I said, if you wanna grab the sources, they are on android.googlesource.com and if you do a repo in it with the Brillo manifest, notice it says here, you know, Brillo, not Android. My highlighting's not working. You do repo sync, you get yourself Android, I'm sorry, Brillo sources, right? It's just a different manifest file. In fact, if I go out to here android.googlesource.com, what's he connected to? No, that's not gonna work. Hey, where's my, sorry. I've got a hotspot, but he seems to ignore my hotspot. I'll just reboot this thing and come back to it in a second. Let me go back to the slides. So I'll show you the manifest file in a minute or two here. Now if you look at the top level of the sources that you get, so let me actually go here, let's change the color coding a bit. Nope, not this. All right, let's go to here, Brillo master. Okay, so this is my top level of the Brillo sources. If you're familiar with the AOSP, you'll recognize most of the directories, all right? But you should also realize that some things are gone and I'll tell you what's gone in a minute here and we'll walk through some of the things that are in this tree. You'll notice that it has same kind of basic functionality. You got a top level make file, which has almost nothing. You do the regular, you know, build, sorry, build ENV setup, SH, launch, that's regular stuff for Android. Brillo uses the same kind of build system, whether you despised it or not, you will continue despising it here. So that's for the build system in. It also has an out directory like Android does, all right? And this layout underneath out is practically same thing, out target product in this case is Brillo emulator, whatever else, and whatever I have underneath here. So what do we got in here? So Bionic is the C library, same thing. Bootable is the OTA stuff, still here. Build is the build system, still here. Device is essentially the, well, directory where you've got the actual BSPs, all right? And you can see the manufacturer names in there. So you've got the Intel boards in here. You've got the Qualcomm base boards in here and all the other ones that they've supported in Brillo and the same way it used to work before. So if you look in here, you've got the Mino board, for example, and this is the information about the Mino board, or the BSP of the Mino board. And if you go in the QCOM stuff, you've got the Dragon board stuff in here as well. All right, and this really is where Brillo shines, which is those SOC vendors, given the market share that we saw earlier, are already doing a lot of work to get Android working on their devices. And by so doing, they're also enabling Brillo. So that's really the genius of this Brillo thing. My suspicion is that the, okay, so if you looked at the very early releases of Brillo, again, you know, I said, you know, I kind of mockly called it the bastard child of Chrome and Android. But interestingly, it seems that it is an effort that stemmed from the Chrome folks. And my suspicion, and I have really no substantiation for this, is they started off with Chrome and then somebody told them, you know, hey, why don't you check this Android thing? You've got this huge device enablement from the Silicon vendors. Well, let's go with that instead. And so that's where, you know, it seems to have merged into this, morphed into this Brillo thing. In external, interestingly, there's a lot more, there's a lot less stuff than Android. In fact, I've got a slide here of what is gone from external. If it was used for any Java purpose, was a library for the purposes of Java or had anything to do with Java, it's just out the window, all right? And you can see there's a ton of stuff that's completely gone from here. In fact, you know, you can do a very stupid, you know, okay, what's the size of this guy versus the size of say, one of my AOSP trees? Let me go out here into, I don't know, 50, which I got. Sorry. So that's 2.6 gigs here and it's two gigs here. Oh, actually, not that big of a difference in terms of size. I'm a bit surprised, although there's a lot of stuff that's gone, that's gone out. Oh, that's what it is. So I'll go back to the top level removals in a second. So that's external frameworks, which is essentially the core of the Android operating system. Noticeably doesn't have a framework space, okay? Framework space is the most important piece in terms of Java. This is where the Android app developer APIs are found and that's where the Java system services are found and it's just not here in Brillo, all right? That's just because of vacating all of the Java stuff. If you sign up for the Brillo beta, you'll see that some people have actually inquired on the mailing list about Java support. You can check those threads up. That's frameworks. Okay, hardware is the same thing as before, which is the HAL, all right? So if I go to, and again, this is one of the benefits of going with this Brillo thing because they're leveraging the HALs from the Android-included hardware and the HAL definitions are all there as they were before. What else do we got? Okay, let's forget about the new helpers, the GNI thing, which I'm not sure why they kept it in there, but anyway, pre-built is the same thing. Products though is new, okay? This is not there in Android, all right? And product is essentially the directory that contains whatever product that you're trying to create, or in other words, what's your Brillo application, all right? And they have some samples here. For example, they have an example LED flasher that'll walk you through in a few minutes, okay? What else do we got here? Systems is the same thing as before, except they now have a few interesting things like WeaveD and WebServeD, all right? Which will, I'll show you a diagram of what this does in a minute. But those are specifically for Brillo. And then tools is another of the Android directories. So what they get rid of from the top level, so art is gone, art is the Java virtual machine, right? CTS is gone, that's compatibility test suite. Dalvik, which also is the same, I'm sorry, type of developers, development docs, all those development stuff, framework space I told you about. NDK is gone, packages, which is all the default applications like the home, the launcher, and I'm sorry, the home launcher, catheter, browser, and so on. SDK, there's no SDK in here, and so on and so forth, all right? You can probably get some of this stuff back in, all right? Depending on what it is that you're looking for. I would presume that bringing the Java back in is probably fairly heavy, but otherwise the rest of the stuff should be, I mean, if it's C-based, if it's a C-Libr or whatever, you probably can get it back in fairly easily. Some stuff they've added to external, so interestingly, you see there's Gen2, because in fact, if you go through the sources, you'll find a lot of GYP files, at least in the older release, they used to have a lot of them, I don't know, I couldn't find .-name, start GYP, how about that? That's still a bit of it, but I remember distinctly then in the older release, they had a lot more GYP files around. Okay, in terms of images, what does it look like? What does it generate? So you can see, okay, it's not a one-to-one comparison, I'm like using a 32-bit target versus a 64-bit one, but you still see that, sorry, the system image is like a 10th of its original size, even though this is a 64-bit platform that I'm measuring it against. There is no RAM disk because they've merged essentially the RAM disk and the system image in a single partition. The user data part image is a bit misleading because this is actually on my 64-bit Brillo here, I've actually added some stuff that is not in the original. And this is kind of like comparing the Android user space versus the Brillo user space. So forget about cache, forget about the SD storage. In the system partition, you don't have app, fonts, or framework. You don't have Java, so there's no need for framework. And you can see that I'm boxing out the system and RAM disk together because they are actually a single image with both of these things on them. Data partition is still the same as before. And if I run this thing, which is my intent, let's do this, lunch, and I was running number 10. Let's do that. No, no, no, that's not the name of it. This is the name, it's Brillo emulator. And let's not run it in 8%. Yes, okay, fine. He doesn't like the fact that I've got this guy running in the background. Out you go. Awesome. So it starts off essentially on the shell right here. There's no QEMU window that opens up because there's nothing to be shown. But I do get a shell here. And I can also use the ADB shelling capabilities I used to have before. So actually, now let's do this. Lunch, no, no, no, no, no, wrong one, sorry, wrong tree. Let's go back to this guy, lunch 10. All right, ADB devices. So for some reason he's got two emulators, one of which is offline, but let me do this. Let's do, actually let me see. Am I connected back to my hotspot? No, okay, cool. There we go. ADB-S emulator 5554 shell. All right, so I've got here essentially, this one is XTD6 based. No, that's not what I wanted, CPU info. So this is just XTD6 on XTD6 in this case. If you look at the top level of the tree, there's a lot of things that look like, you know, ACCT, you've got the init environment, you've got the system partition, a lot of the basics of the file system are the same. Most noticeably, as I mentioned, if you go underneath system, there is no framework. All right, you've got many of, much of the same functionality, so get prop, you know, still global properties from Android, they're still here. You wanna look at the list of processes, you know, there's a lot of stuff that comes back, service manager, they've got media server and so on. And I'll show you in a second here what the difference is in terms of graphs between Brillo and Android. Obviously, you've got WebWeebD and WebServeD, which are the Weave-specific things which are being run on this device. So let me go show you data, sorry, local TMP. Let me show you the difference of graphs between those two things. Let's go here, node, app, this, and now, let's open another window. That, launch this, e to be forward. Oh, sure. Yeah, why not dash s. Go back to this guy. Let's go to local host, 3000, great. Is he running? Oh, yes. They don't mount debugFS by default. Debug, FS, none, sys, kernel, debug. So we're using for the, that binary explorer thing we're using, we're reading debugFS to get the information that we're displaying to you. And, nope, the other window. Hello, computer. Well, he does have more stuff than this. Let me try again, sorry. Well, worst comes to worst, I'll just show you a screenshot, but this does work. Okay, let me grab, let me grab the screenshot from, let me see, just give me one second here. That, let's do that. All right, it should look like something like that. I'm sorry there, for some reason my display here is not working, but you see that essentially you've got a lot more, a lot less stuff, right? And last things, a lot less things running. What you, what is interesting though, is that you can see that web serve D is actually, and we can't see it here, but this would be weave, the weave daemon. So essentially they're using now binder instead of debus to have the various brille of weave components talking to each other. And what this looks like in terms of say, diagram if you want, is something like this. So the connections coming in from the cloud are going to web serve D, which essentially just is a basic web server, all right? And weave D registers with the web serve D to tell it, hey, you've got queries for these URLs, or in other words, you know, there's essentially a rest queries. It says, okay, I can handle that, that, that, that, that. And then when the queries come in for those URLs, essentially, they get handed off to weave D, which then hands off the query to libweave, which actually is the meat of the protocol. And then libweave parses it out, and essentially hands it off to whoever is registered. And then the applications, or who's registered to actually get those queries, will use the how to actually talk to the hardware. And let me show you an example of that. How much time we got? Oh, we're almost done. All right, let me hurry up here. Let me go back to my shell. So if I go under product, Google example LED flasher. So there's an LED flasher service. Oh, in fact, let me, before I do that, in common, AIDL, Brillo, examples, LED flasher, there's an AIDL file. Who knows what an AIDL file is? So AIDL is an interface definition language file, which essentially specifies communication between two binder parties, all right, a client and a service. And this is essentially the API that the service will provide. If you look at the service itself over here, in its main function, all right, it'll essentially initialize itself, which we'll call this part here. And this essentially registers the service with a name over to the wrapper. And on the other side, the LED flasher itself, I believe. Was it the service? I can remember which one of these guys. Oh, service, actually status. This guy does an HW get module, all right. Anybody know what that is? That's a call to the hal layer, all right. We're actually asking the hal layer, get me that lights hal module, all right. And if you kind of follow the code, I don't want to kind of lose everybody here just by walking through some code. But the idea here is I wanted to show you, we're talking to the hal, we got a service talking to the other side over to the weave daemon. And essentially when it gets the request, it's essentially gonna call into the hal layer, straight out, all right. There's no call into the system service to go to the hal. It's straight into the application, in this case, this lights flasher. And if I go out all the way to the top underneath external, and I go for LibWee, which as I said, is the parsing thing that actually takes care of demangling all those arrest queries. If I go to, I think, examples. Was that it? Provider, no, daemon. There we go, I think, read me here. So in the read me here, they actually have kind of like a how to get OAuth tickets and essentially send the queries, and you can see essentially the device getting, there's a console for this, there's a weave developer console, there's an app, and essentially you can register your device with the console and have the app actually talk to it, and you can see the queries coming in from the weave protocol, all right. That's the whole benefit of this weave thing, is essentially you've got this cloud service that Google houses to actually send queries to the devices that are registered. And so what I had taken a look at that, at least kind of like my 30,000 foot view of it, was that it probably wasn't too hard to replicate what they were providing on the server side, because the protocol's actually not that complicated, at least again, from an initial analysis. And interestingly, somebody actually did implement a Node.js based weave server, so if you don't, presumably, and I haven't tested it myself, so I can't even tell you whether it's good or bad, but there is code out there that if you wanted to implement your own weave service instead of having Google provide it for you, you can probably start from that code if you want to take a look at it. I think it's called, and I'm gonna get this wrong, or Weavey8 or something like that, which is kind of like the re-implementation of this. What else did I wanna tell you about this before I sign off here? So I showed you the PS list, I showed you that much of the stuff in here. What else do I wanna point you to? Yeah, so okay, one thing I'm not doing here is actually showing you the site that they provide as part of the beta to people that are part of the Brillo beta. You can sign up for that if you want to, and they take a different perspective on things. As I said from the beginning here, I'm looking at this from a very specific point of view which is can I leverage this as a stripped down embedded Linux based on Android, and yes I can, right? But they're taking a different perspective which is helping you create IoT devices with this, and so they have references on how to do that. They have boards described on their website and stuff like that, and you're free to sign up and get access to that and look at what the material they have for you there. And so from my perspective, having been doing a lot of Android work, I like the approach they've taken with this. I hope they actually have some success because it gives me an alternative to Yachto and Buildroot. I have nothing to say bad about either of these projects. It's just that I think that in terms of device enablement, Android's got that pretty well nailed down with most of the SoC vendors and being able to leverage that off the bat for an embedded Linux distro is pretty cool. Obviously, it is yet not released, okay? So what happens with it for real afterwards is TBD, I have no idea. But it's interesting to see that they've been able to, as I said, reuse Android pretty much as is, and this is the bit I wanted to show you earlier and I could not, so let me try to see if I'm connected now. Great, my hotspot went away again. Okay, whatever, sorry, bad hotspot. If you just go to androidgooglesource.com, you should be able to see that essentially they've got, instead of platform manifest, they have Brillo manifest. That's what we wanted to show you here. And then you grab that manifest and you can start playing with the sources and everything I showed you here, I just deduced from actually looking at those sources without actually referring to their documentation. Yes, sir. Do I have any insight about Google's plan to replace the kernel? I don't. I don't know that they have that intent. There's a lot of speculation going around. I mean, if you go back historically, I think it was Brian Swetland that had mentioned on Linux Weekly News in response to one of the posts that they had actually used Linux, they had looked at BSD, actually they had seriously looked at BSD, the BSD kernels, but they found that the SOC vendors knew much more how to deal with Linux than with BSD and that's what kind of pushed them in that direction. And so the question today is still going to be the same thing, which is what are the SOC vendors familiar with? And that for me still remains, Linux to a large extent. Hey, maybe Google can use their 800 pound gorilla kind of like weight to push people in some other direction, but I've not seen that actually materialized. And I'm not hearing from SOC vendors, Google met us in a secret meeting and they want us to go with Fubar. Might get happened, but still were. I think we're good with Linux for a short bit. But interestingly, with regards to Android, if you look at the compatibility definition document or whatever they call these days or compliance definition document that they used to call it, they don't actually require you to have Linux for running Android, getting certified as an Android device. They want the Unix capabilities of a Linux-like kernel, but they don't actually require you to use Linux. In fact, they don't even require you to use the EOSP. It's just so happens that by using both you're kind of complying. If that, I know it's not a direct answer to your question, but that's the best I can make. Yes, sir? Sorry? What about what, sorry? Oh, Magenta. So that's something that I'm still... What about Magenta? So big question mark, I have no idea. I know there was an announcement about that and I was still trying to grasp what the benefit here was and who's pushing. Because from the outside, Google looks like a big monolithic box, but inside of it, there's plenty of teams. So what's the team pushing that and what are they doing with it? I have no idea at this point, but I'm keeping an eye on it for sure. Yes, sir? Granted. Correct, granted. So the gentleman makes a very good point, which is my first initial point was with Android, you get the benefit of having a tremendous amount of users or developers that know how to code for this and all of a sudden, hey, we stripped that away, so what's the benefit of this here? The benefit that you get here in the way they've at least packaged it for now is that you get the same platform enablement that you had before. So if you had been doing platform work in Android before, this is still fairly similar, but at the platform level, not at the application level. So if you were using HALs, if you were familiar with using HALs and that kind of thing, you're still in the same kind of framework to a certain extent, but you're right. Yes, sir? Yeah, so with regards to Brillo, there is this aspect where they're trying to get everybody around the same kernel for security reasons and such things. I am, to be honest with you, I haven't investigated that enough to be able to speak of it, but I know there is contrary to say standard Android where everybody can use whatever kernel they want. They want people to use a specific kernel such that everybody's uniform across the Brillo devices out there. That's as far as I can go. Oh, okay, that's interesting. Okay, so essentially what you're saying is that they, the SOC vendor will have to conform to whatever they, the kernel they specify, not the one that they were using. Okay, I mean, but hey, more power to them. They're gonna be able to push the SOC vendor to upstream their stuff. I'm not gonna complain about that. Yes, sir. Sorry. Yes, go ahead. Okay, so, okay, what are the risks associated with using this? So my standpoint with Android has always been that if Google stopped developing it tomorrow morning or if they closed sourced it, there's such momentum behind it that I am not afraid that somebody would pick it up and go with it, be it signage and mod, be it somebody like Alex Foundation or what have you. I think there's, Google can try to control it, but I'm not sure that I see exactly how they could do this. With Brillo, it's essentially the same thing to a certain extent insofar as they are able to catch some, if there is going to be some kind of traction behind it, I'm not sure exactly how they're gonna be able to control it. The licensing is fairly similar. In fact, in the Android's case, the way they control the ecosystem is through a trademark. It's kind of a bit brilliant. They give everything away except they control how you use the trademark called Android. And so, my concern is really just an annoyance. I mean, it makes sense from their business perspective is this thing about going through their cloud all the time. It's like, hey, you know what? I wanna run my own servers. I don't want my data to go through you, but that's a personal opinion. I mean, it doesn't take anything away from the usefulness of, if they're pushing this from a consumer's perspective, and so kind of tying, I don't know my fridge and whatever else to some other services they have, it fits in what they're trying to do. There was a question. Yes, sir? Yes. Oh yeah, so what are the permissions for the applications and such? Or the weave applications? I don't think the strict permission model that Android has fits in this. I think really what they're leveraging here is the fact that you've got a common base between Brillo and Android in terms of libraries and such, and also in terms of HALs. Beyond that, you could run those apps, the Brillo apps or weave apps as whatever user that, I mean, I wouldn't bother with that. I would just use whatever user I can, will work for my application. Right, right, right. So the signature mechanism there is non-relevant because essentially we're running in C, and so there's no signing of the binaries going on here. It's a custom device with a custom set of services, and the user's not gonna be able to side load much there, at least not that I can see. Yes, sir? Yeah? Mm-hmm. Yes, okay, so do I think that Brillo would cash the, you know, will it be able to accomplish the same things that Android did on the user platform on the embedded side of things? So when was it? Two, three years ago, at one of the ELCs, I can't remember, I was invited on a panel, and we were talking about the different distros, so somebody was there with, I think it's Tim, we're representing Bakerone. There was Thomas Pizzazzoni, we're representing, obviously, Bildrude, there was myself, and there was another gentleman representing, I think, Yachto, I can't remember, it's a bit vague in my head, but when asked about something similar to that, my response was, I do think Android's gonna eat the whole thing. Just because of the SOC enablements, that's the thing is SOCs are, SOC event is already enabling Android, right? Thereby they're enabling their chip for specific usage of it, and if you strip that down to something bare bones and run whatever you want on it, then hey, you guys have a lot of distribution, plus it's already specced for you, you don't have to select libraries and such things and so on. It remains to be seen, I mean, there's a lot of, so Linux historically ate all the build your own operating system things that were there, say, 15 years ago. But the nice thing about Linux is exactly in embedded, is the organic nature of it, which is I can take it, I can customize it to my needs and not care of the rest. Maybe this becomes a base for something, we'll have to see how the market reacts to this. I mean, for now they haven't even released it yet, so it's really hard to grasp what's gonna happen. Yes, sir? One last question, yes, sir? Yeah, one of the big differences between the AOT market and it's plastic and uncoated for life's sake, plastic and uncoated for a short period of time, and when you listen to a lot of other talks, for long term support, you want to be close to the main line. Absolutely. How does this work for this, because you're talking about SOC enablement and there's a lot of that, and typically the things that the SOC vendors would have aren't very close to the main line. So it won't be better off with a main line and not very close to the SOC vendor house. Sure, I mean, so are we not better using main line versus something baked by the SOC in terms of, for sure, I mean, if you use something from main line, it's better, but there are a lot of systems out there that have been put with two, four kernels, or even two, two kernels. They've never been upgraded to anything. You know, my worry as we go heavily into this IoT direction is that more and more devices in society are gonna be based on things that are never gonna upgrade it, but I don't think the issue is with Linux. I think the issue is with the business model surrounding those devices, which is as a manufacturer, you wanna put a device out, sell as many as you can, and then move on to the next one. There's almost zero incentive to go back and support this other legacy product that you put out there. So the issue is business model is more than, I think, specific software support. I think there are certain things you can do on a software side that make it more palatable if you do wanna maintain long-term serviceability, such as using LTSI or whatever else, but ultimately, it comes down to, are you willing to pay when you put something in the wall for it forever? Because that's really what it has to go to. If I put something in my wall or a medical device or whatever, the manufacturer has no incentive to make upgrades, unless I'm continuing to pay for those upgrades to a certain extent. And I think that, as consumers, we're not really, we don't really want that. We wanna buy something and never upgrade it. And the other side of the same thing, the manufacturers are doing the same. Yes, I mean, I think it's a business issue more than, sorry? The same price, why don't they give you free updates? Yeah. And why don't they give you an update at all? Well, if you are interested in that, then you will. It's an interesting, it's a- I don't think they use it here too much. I'm with you, but I think at the end of the day, it's a more a business discussion than a technical one. Yeah, yeah. I think we're pretty much done, in terms of time, and a bit over, so I'm happy to take more questions after the talk if you want to. Please come up and ask me what you want, and I'm gonna be here until tomorrow end of day anyway. All right, so thank you very much, and enjoy the rest of the conference.