 Good morning folks. No eggs, no tomatoes here. What we want to do here is talk to you about what is happening in the meta world with open source software in general. So Tim, Mike, David, Zach, if you could please come up here and grab a chair. So before we actually get started, if you guys could just present yourselves, you know, what you guys do so that everybody knows who you are, please go ahead, David. Thanks. I'm David Stewart. I'm an engineering manager at Intel, and hopefully my voice will stick around all day. I am a manager of our embedded Linux effort in the open source technology center, primarily working on the Octo project. Chief technology officer for the PTR group. Been in the embedded business a little over 37 years now. My first embedded systems programming assignment was an Intel 8080 back in 1976. So, go back a ways. I've seen your staff software here at Sony Network Entertainment, and I work on Linux for various Sony products. I also involved with the CE workgroup of Linux products. All right. I'm Zach Pfeffer, and I'm the Android lead at Lenaro. And I've been working on Android since it was a thing. And I've been working on embedded Linux for about, I guess, 12 years. Awesome. All right, so what I'm going to do here is before I actually lay the questions to the panel, I want to go through about four or five slides just to actually lay the groundwork as to why we're even asking this question. You know, why do we need to ask this question and, you know, kind of have a conversation around it? And I'll tell you right away that the answer can't be a flat yes. I mean, there's no way that that's happening. The question is, of course, a conversation starter. So just to kind of give you an idea here, these are some graphs I picked up from Ars Technica that ran an article in August, giving you kind of the markets for smartphones between 2000 and 2006. As you can see, there's kind of like a spike somewhere in there for Linux, and then it kind of dies away. All right. Just kind of disappears out of the chart. And then somehow later on, kind of Android kind of takes off. All right. So of course, we're here because Android is gaining a lot of traction in the market. And this is also kind of correlated to this chart here where you can see that smartphones are outselling almost everything out there that lives in Breeze. And, you know, this somewhat has an impact on, you know, software development in general. Okay. The other thing that I picked up at some point actually through an article that the Linux Foundation was running on Linux.com, I think. So, you know, what operating systems are you currently using? You know, as you can see, Android's up there alongside Ubuntu. And then what are you looking for in the next 12 months? And you can see that Android is pretty high on the chart. Okay. So this is what's prompting the question being asked here is, you know, where are we going with all this? All right. So the first question I'd like to ask the panel here is, you know, can you define what Embedded Linux is and what is Android in contrast, so to speak? Actually, the question of what Embedded Linux is, I'd like to ask Tim to answer first because he told me that he had some alternative. I'd like to actually see if he could answer first. Okay. So. Oh, you got a mic on. Yeah, they said my mic's not working, so. Oh, there you go. So, yeah. So I actually don't think that Android is Embedded Linux. Okay. Perfectly fine. Well, so let me, but I have to tell you my definitions. Sure. Absolutely. Absolutely. Embedded, to me, means a single function device. Well, not a single function, but a fixed function device, right? And for years, at least in the consumer electronic space, we've been dreaming about making platforms out of our devices, particularly television sets at Sony, you know, how can we make application ecosystems around it and run third-party apps? And that's all well and good, that's great stuff, and we're seeing that happening, you know, there's Google TV and all kinds of smart devices that allow applications to come on, but for me, that's not traditional Embedded. And traditional Embedded is, you know, when you bake it at the factory, that's what it does, and that's what it will do for the entire life. So Android is more of a platform play, and I think that's kind of the big difference. And what we're gonna talk about, I guess, more today, is can you take a platform operating system and use it in Embedded? And an easy answer right out the chute is yes, but we'll talk more about some of the details. Sure, absolutely. Anybody want some vision? Yeah, I mean, relative to kind of my understanding of Embedded Linux is, you know, kind of separate, embedded in general, I sort of think of is different than cell phones and tablets. Sure. And I think that's a relatively well understood, you know, division. So from my standpoint, I never want to say, well, you know, Android, I mean, my company, you know, does a lot with Android. I mean, we had Mark Skartness here yesterday talking about all the investment and the tools that Intel's making on Android, primarily the focus is on the cell phone and tablet space, and then for the rest of the Embedded, you know, we have focused on something different. And the Octo project is primarily the thing that we're trying to work with, you know, our partners like TI Wind River and Mentor Graphics, and I'm sure I'm missing a ton of others, but generally the community, open embedded community to try and deliver that bit. Cool. Mike? I think they pretty much covered it. Yeah? All right, Jack. I'm going to take a contrarian. What a surprise. And I'm going to say that Android is embedded in Linux. Okay. So can you define the former and the latter? Well, I wouldn't say it's a non-upgradable, but it's a limitedly upgradeable device. Okay. You tend to pull it together. You know, you don't tend to upgrade the platform so much as you might upgrade, you know, user space or apps that run on it, and that's been going on forever in embedded Linux. So I think that Android is a successful, embedded, it's used successfully in the embedded Linux space because it actually is a, it achieves those goals that more traditional embedded Linux, Linux has strived, have been striving for a long, long time, and that's why it makes so much sense. So I think that, you know, embedded systems as a whole are just a means to an X, right? The thing I need an operating system because if I don't have an operating system, even if it's an executive, still an operating system, right? I need to make the chip work. And, you know, embedded Linux has been a good way to do that. And now that we're entering this world where we have SOCs that integrate so much technology, so many IP blocks, and these SOCs are connected in ways that we have never dreamed of before, that Android is just a particularly efficient way to handle that new paradigm. It might even go so far as to say it's enabled that new paradigm to even exist in the first place. Okay, good. All right, so to kind of follow up with that, I thought I'd get your point of view here on, you know, why do you think embedded Linux at the onset, you know, say 12, 13 years ago kind of started to become popular? What were the drivers there that kind of made embedded Linux the compelling thing? So for example, the T-shirt for DELC later this week is, you know, have you ever used, you know, TV, blah, blah, blah, blah, blah, blah, blah, blah, blah, and then thank you at the end because, you know, embedded Linux is being used everywhere. So what kind of prompt at this? I can sum that up in one word. Sure. Royalties. What? That's awesome. Or lack thereof. Or lack thereof. Or lack thereof. That's a good point. Well, yeah, royalties is a big deal. I used to, I was CTO at Linio. Yup. Really? Which is, it's an embedded company, you may have heard of it, it's gone now. But, and in the early days, like 1999, 98, somewhere in there, and when we were out there trying to sell Linux in the embedded space, it was kind of hard. But the compelling things were the royalties was a big issue and the other thing was just the availability of the source. The fact that you could, that once you got that source, you did not have to talk to your supplier again. And it's not that people didn't wanna talk to their supplier. It's that they often could not talk to their supplier. Right. It was, you know, getting the time of day from whoever provided you the bits. You know, and especially if you were a smaller shop, you know, the big companies can get, you know, support from their vendors, but the smaller companies, it was really hard. That's why you still see, I mean, you still see in this chart, you see a lot of in-house stuff. Right. So you're wanting to see that. You know, the other thing I would say is a lot of people make the assumption, I think that with embedded often means real-time. Sure. I mean, a lot of people I know have come to me and said, oh, you know, is it real-time Linux? And it's like, I think there's been a dawning realization that you can achieve the vast majority of what you want to achieve in embedded without a classically real-time sort of oriented system. Sure. Certain applications that will, you know, require hard real-time guarantees and are happy to throw away latency, you know, for the, you know, essentially they get the guarantee. I'm not a real-time guy. So I'm trying to mess up the definition. I've got one real-time guy that works for me and I gotta be careful. Every time I say something, he goes, no, no, no, Dave, it's this. It's like, oh, yeah, yeah, right. But, you know, that's some of the factor that I think has also helped Linux become, you know, certainly the source code and the lack of, you know, the free end, you get the source code. But also, I think there's sort of that aspect. Hey, Linux is really capable in a lot of situations you might otherwise have had to buy, you know, a real-time system for. The other factor is I think there are companies coming along now and providing a lot of the certifications that otherwise would have been, you know, whether they're safety certifications or government certifications, health certifications, et cetera. All of these now are, there's an ecosystem now that I think can deliver a lot of that. Real-time means being fast enough. Right. So as long as you can meet your deadlines, the question is how much energy and how much money do you have to put in to making that happen? Right. And I used to be a VxWorks guy, a long time helped contribute a lot to the VxWorks kernel back in the day. And so when people first started talking about embedded Linux in like 98, we laughed. Yeah, we know. But then over time, we started seeing some significant changes, the preemptor T-patch. Right. Someday maybe it'll actually make it totally into the kernel, who knows. But it's getting smaller and smaller, so we're making progress there. And one of the groups of my guys are working at NASA on the space refueling robot. Sure. And we're using embedded real-time, well, it's, you know, we're sitting on top of Xenomai, but we're sitting there and we're running Linux. I mean, that's in orbit. Awesome. It's proven itself to be a reliable operator. Absolutely. Zach? Yeah, well, I think all those are valid reasons. I think one reason, in addition to those, is that Linux is fun. And, you know, most of these distributed, or not distributed, but disruptive technologies come about because, you know, an engineer at some company, you know, is looking for, you know, they like to do fun things. Right. And they may have, you know, Linux is a hobby and they think, oh, well, I'll pull this hobby into my work and they have a manager that's maybe a little more enlightened to the universe or maybe is just cheap. And it's thinking, yeah, sure, that's great, let's do it. And so I think that, you know, there is that element of it's just a lot more fun to work on an embedded Linux system than it is to work on, like, a windmobile system. I mean, you know, having put out a windmobile system, I can tell you. So my next question is, given that, you know, given those things that have attracted people to embedded Linux, what's attracting people to Android? You know, I'm not an Android guy, so I will admit that. So from my perspective of why, you know, I see some of that happening, I think there's an attractiveness to the familiarity of the UI. I don't think it's actually because of the App Store. Because I think in, although there are some applications where I think in automotive, for example, people would love to get access to Google Maps, right? And there's some challenges there, I understand. So, but, I mean, relative to, generally speaking, how we've defined things, I think there's not as much an interest in them at the apps and services as much as there is. Well, there's a familiarity. Somebody who was saying, well, you know, if you're doing a military application, you've got soldiers who are 18 to 24, and they've got, you know, they're used to the pinchy zoomy swirly thingy thing. You know, then that's, oh, well, let's just, you know, throw that over. So I absolutely see that as an attractive element. The flip side of it, though, is, you know, it's easy, and I, you know, I'll be kind of blunt. I think it's easy to hack something together, right? And the challenge, I think, is, since most normal humans don't get insight into what Google is gonna do with Android, because it's not a true, what I would consider- Absolutely. Does anybody really get insight as to what Google's going on? Well, I don't know. I don't know. I'm not sure that anybody here can hear it. That's a lot of insight. But, there may be some Google people who could, I don't know, but the- No, they won't. Okay. So, the, you know, it's always possible within this Linux sort of heritage that we have. You know, it's fun. You can always hack something together, right? And that's, I think, probably true of Android as well. Take the latest dessert-flavored release, and you've got something that you can put together. But when the next one comes out, and all the middleware has changed, all of your stuff will have to get redone. You know, and what we're trying to do with the OctoProject is actually for, you know, I think engineers, if they go beyond saying, okay, I can want to, you know, maybe put something together, but I want a sustaining business. If I'm gonna have to redo what I'm gonna, you know, do for the next thing, and redo it again, most engineers would rather eat the muzzle of a revolver, rather than actually have to do that, right? You want to actually engineer things that are repeatable that actually are efficient. And so, this is one of the driving purposes around something like the OctoProject, which has, you know, portability around these layers and complete transparency. If we're changing a package, a package version, or a changing approach, everything is totally transparent, and people can comment on it, and if they don't like it, it's very easy to override through the layer architecture and all that stuff. So, I want to make a, you know, but basically that's one of the things I think is really, you can always hack something together, but do you really want to have a career of constantly redoing that stuff with the next dessert that gets thrown at you? Sure, but I think you can't underestimate the familiarity aspect of it. I mean, as somebody who's involved a lot in training, you know, it's being able to drop a new industrial piece of equipment onto a factory floor and have somebody walk up to it and go, oh, I know how to work this. You know, the pinchy zoomy thing is an important UI. I mean, that's an important user experience piece. Right. So it's a familiarity that people just go, oh, okay, I instinctively know how this works. Let me run the Angry Birds app while I'm pressing this piece of aluminum. Great. Well, okay, so from my perspective, one of the big significant effects that Android has had on the embedded Linux space is that all of the silicon vendors do an Android port first, right? Probably before they do X or Wayland or anything else. And so you see, and there are still GPUs. Not necessarily. Well. Every silicon vendor. Not every one. But keep going, keep telling me what we, you know, keep going, Temple. There's a company accepted. I mean, I won't, you know, we could talk about what Intel does, but we'll get to that. But there are a lot of ports available. There are a lot of ports available. There are a lot of ports. And so the, what you see is you see a lot of silicon support, silicon vendor support for the Android stack. Particularly a thorny issue is the support for the video chip or IP block, whatever it's gonna be. And so a lot of people using Android other than in phones is coat tailing, right? Is you don't want, if I'm developing something from scratch, I don't want to go ride a video driver. Right. And you know, and they eventually show up in the open source community under kind of standard embedded Linux, but sometimes it takes longer, depending on the chip. So the availability of the support for the very silicon pieces is a driver there. Certainly. I mean, if you take a look at what's happened over the past few years, Android has been the club that has finally gotten some of the most uncooperative silicon bags to find the cup of the table. But that has been the club that's finally gotten them to realize that open source is not the evil empire. Gotcha. Zach. Microsoft is. I think transparency is fine, I think. Anyway, I think the most important thing, the reason why people are moving to Android is that all that actually doesn't matter. What matters is the API level. Okay. And the apps is key. App ecosystem is the only thing that matters. So the API is what's driving people, do you actually use Android then? There is a clear value proposition there. Okay. There is a clear ability to say, I can take and build a platform that people can monetize and people can then write apps against. And I totally disagree. There, you don't need, you do not need to know how the sausage is made to eat the sausage. And in fact, the only thing you need to know in the Android platform is what the API level is. And then you know, well, the API level isn't gonna change or it's gonna be backwards compatible. And if you look at how Android's put together, the API level is the contract with the user. And in fact, Google intentionally does not document how the platform's put together because they don't want people to violate the API contract. Because as soon as somebody violates the API contract, they are no longer in the ecosystem. So, and from an application developer's perspective, they don't care how it's put together. They don't care how the video gets from A to B. They know that if they call one of the, an RTP video stream interface on their Java, on this Java class that's been exposed to them, they know it's gonna work. So let me ask you a question, because I'm, oh, sorry, go ahead. Well, that depends, right? If they're doing their own hardware, then they are gonna have to know the low-level bits, right? And so, if you're using Cots, off-the-shelf hardware, fine, you can just stick to the Android APIs. But, I mean, you've gotta do some system work. If you're building your own board, if you're trying to shave, you know, sense off of the hardware designs. The other question I was gonna raise was, Something I'm familiar with. Yeah, right, something I was gonna say is I've heard, again, not being an Android guy, but I've heard that there are plenty of tablets without any cell connection that's still dialers. Right, right, you know, so you go, it's, Yeah, in Froyo, you couldn't pull the dialer out even if you didn't want it. So you had to hide it somehow. Okay, so this is it, you know, so what I've heard, again, I'm not an Android guy. What I've heard people say is that, you know, the sort of monolithic nature of it makes it really tough to pull stuff out. And then when you do want to, you know, to either save on boot time or footprint or any of those sort of things, which is kind of a constraint. Not everybody has a, you know, Xeon class processor for their embedded. Although, if you do, you know. Yeah, which actually brings me to the next question, which is, okay, so, these are kind of like the drivers bringing people to Android. What's the drawbacks of using Android? You know, when you're gonna choose to use Android, what are you taking with you? Really big footprint. And if you stick to Java, I'm sorry, but the JIT is slower than native. I mean, so you're just, you're, Okay, so speed, You're gonna, it's a classic classic trade-off. You know, it's the embedded trade-off of, you know, historical embedded trade-off that we've all dealt with, which is, you know, how much, how much time do I spend pairing stuff down in order to reduce, you know, things like the amount of RAM I need, or the megahertz that I need on my CPU, versus can I just take stuff off the shelf? There was a really interesting thing that happened a couple years ago. There was actually the very first video advertisement in a magazine that what they did was they, it was an Android, someone had gotten a very inexpensive Android phone and stuck it, stuck the board inside the page. Yeah, oh, was it a, yeah, I remember that. But there was a limited edition, right? The magazine, yeah. It was a magazine ad that was running video ads, and they just took Android, and it was a very, very thin cell phone that was stuck in the page, and they turned off, it wasn't doing, it wasn't doing Wi-Fi, or it wasn't networked, but it was doing all this pages place. But it was $50. And so it was a limited edition magazine run. They're only, you had to be getting like the first thousand issues of this magazine. Right. But so that's the trade off, right? You're not gonna see $5 for that if you're talking about a processor that's capable of running the whole stack. Okay. And so that's your cost, right? So I've got it, I kind of have a counterpoint to that, which is I think that if you look at the applications that embedded Linux has covered, right? Let's separate out MMU-less and MMU, right? If I've got an MMU and I'm running Linux anyway, I've got a certain class of embedded system. And I think that Android fits all of those systems, because you can get Android down into a 64 megabyte RAM if you want to. That's okay, my digital still cameras at Sony or at 32 meg, so sorry. So other than all digital cameras? What I mean to, yeah, I mean, that aside, I don't think that there's anything in Android that actually precludes you from going really low. Well, I don't know, all you had to do was sit in Kareem's presentation yesterday and Sasha's presentation later to see the seven layers of software that keep you from the hardware. And all that software, whether it's written in C++ or Java, takes up memory. And as we see now with ICS and later, if you don't have a high-end GPU, I'm sorry, you're not running ICS, at least not in a way that a user is gonna be able to tolerate for very long. That's actually not, that's not completely true though, because with a, I mean, you can do, if you really wanted to, you can do a software rendered UI on a lower resolution screen and that becomes actually pretty viable as you have these more powerful SOCs that are continually coming out. Yeah, you don't even need to necessarily hook up to the GPU. Dr. Moore has really helped us a lot of these things, but certain technologies don't actually moor all that well, you know? So anyway, yeah. But I mean, your original question was, you know, what is bad about Android? So we mentioned the footprint, I think that's a valid point. Maybe I can get you guys to elaborate, see on the, and we talked about the complexity of the stack, maybe about the community angle or lack thereof. Oh yeah, that, yeah, don't get me started on the community. Well, so, okay, so if you're gonna, there's not currently, to my knowledge, and maybe you're working on this, but there's not a community effect for like headless Android, right? Yeah, it's difficult. You're writing on the coattails of Google and you get whatever the next release of Android that Google puts out, that's what you're gonna get. Sure. And because of the nature of that, it's really hard to create a community around it, right? Because you, one of the big aspects of working in the open source community is being able to push things that you want in the future upstream. Right. And you don't have guarantees there. Well, you don't have guarantees in the regular community either, but it's a little bit more open. You got a fighting chance. And so, I think that's a big issue, is whether or not there's gonna be a community to support. Like, suppose you wanted to do something like add toy box to a headless Android situation, right? Situation, right? So Google's doing toolbox and, you know, they will probably never adopt toy box. So they may or may not, but it's out there and even if you put a whole bunch of work into it, you'd have to maintain it on the side. And so there's a whole issue. There's kind of an extra layer of development effort that would go along with building a community around Android. And I think, here's the other thing that I thought I'd think about. I mean, I really resist the idea of saying transparency is a who cares, particularly in this room where, you know, where the Linux Foundation is, you know, whole concept is based on the premise that a community effect, the transparency, the cooperation is the power behind Linux. Frankly, I've been in the industry long enough. Not as long as Mike, apparently. But, because my first project was an 8088-based one, not an 8086, so that's, wow, you know, that's pretty impressive. But you show it well, you know. But I would say, you know, I've seen enough companies that people go, oh, this company is never going away. They're always gonna be there. And, you know, honestly, I look at where, what's Google monetizing? Now, I don't know Google, and I love them. They're a great company. I got an Android phone. I love my Android phone. It's awesome. But if the time were ever to come where they would say, you know, we're not interested in doing this thing anymore. You know, we're really left in a, we're kind of left holding the bag, which I think that one of the powers of the open source community is one in which, you know, we're able to cooperate together. And I'm not saying that this is gonna happen today or whenever. Who knows? Any company could decide to, you know, make a change, right? You never know. But I think that's one of the things that's really interesting about a cooperative environment that we can work together for that stuff. I was gonna also address your question about whether chips, you know, every silicon manufacturer comes out with Android first. I thought I would, you know, one of the things that we try and do with our chips is we try and really make it up to a customer's choice. So if somebody wants to pick even Windows embedded, okay. All right. Not my deal, man. But if they wanna pick Android for any application, that's what we really wanna encourage people to do. We wanna make sure it runs best on Intel. That's just true of also Linux. We do a lot of upstream contribution to Linux in all, not only with Adam and Core and Xeon. All of those processors really make sure they all, you know, run Linux. We're hoping best, right? So we do a lot of upstream work relative to that. So yeah, if a customer wants to do something, you know, we're okay with it, but we sort of love the opportunity to work together with even competitors and a whole sort of ecosystem on something that really, you know, will succeed. That's kind of why we're focusing and embedded on the after-project. Yeah, well, from my perspective with the embedded piece, when you start adding PWMs and exporting I squared C and spy and all the industrial controls that go along with that, now you're talking about things that, you know, have you ever tried to modify lib sensors to add a totally different sensor than what Google thought should be in a phone? That's not a trivial thing to do. And so from the does Android replace, especially headless Android, replace, you know, an embedded Linux environment, it's not trivial to add a totally new type of sensor to Android. So, you know, if you're gonna try and put it in a refrigerator or a washing machine or a temperature sensor, you know, you need to be able to do barometric pressure for whatever reason. This is not an easy thing to do in Android unless you're willing to really dig into the AOSP and understand how it's all put together, which is why you sell your book, right? There's an appendix about that. You wanna take a stab at that? Yeah, so I tend to agree with David and in terms of this, one bad thing about Android is kind of once you go Android, you're in Android. You need to port libraries by and large. You need to think and design your software to use Android, which is not necessarily a platform at that point, but you're adopting the Android operating system. Object-oriented operating system, which is at the core of the Android system. And that is a fundamental change. It's actually a fundamental difference in skill set because now I am no longer opening a POSIX pipe to talk between demons, right? I'm writing a Java service that's going to serve, serve activities that I'm also gonna write. It takes that level of abstraction and has shifted it. And so I think, yeah, what I see when companies choose to go with Android, it is kind of a one-way ticket. And I think companies that do adopt Android and say, we're going to re-architect our existing software to make use of the native platform, I think they reap a lot of benefits from doing that because of the way things are constructed, but it is a one-way trip. Sure. Okay, and I'm kind of leapfrogging on that. So one of the things that first struck me when I kind of approached Android, I mean, I got into Android thinking, hey, this is in better Linux, this is gonna be easy, right? And as Mike said, you just get the layer of cake. So I was wondering if I could get your opinion on the fact that Android has rewritten some major things that we've been using in the embedded Linux world for forever, right? So stuff like Big Box got rewritten as Toolbox, G-Lib C, and Micro-C-Lib C got rewritten as Bionic. And there's quite a few other things. I have a very strong opinion on this. Okay, go ahead. And it's actually, maybe surprising to people, it's very positive. When I first looked at the Android stack, it was such a breath of fresh air. It was like, I'm not trying to wedge Unix into the embedded space anymore. It was designed from scratch, from the ground up, with embedded issues in mind. Okay. And so the fact that it's not strictly POSIX, doesn't, well, I mean, it bothers some people, but it's like, oh, they've discarded some of the POSIX badges. It doesn't need to be here anymore. They did Toolbox for kind of dumb, well, not dumb. They did that for license reasons, right? Yeah, I don't want to get to that, but later on, but. Right, so, but the other stuff, like, some of the stuff they did around application life cycle, with Intense and the message passing is neat stuff. And like, the way they handle crashes, the way they did the logging is different than traditional Linux, and it's way better for in the embedded space. Right. And so I've been wanting to see a lot of that stuff pulled back and somehow put into, you know, non-Android stacks. There's a lot of really good ideas in the Android stack. Somebody else? No? All right, so, kind of going from there, what can embedded Linux, so to speak, learn from Android, and vice versa, in fact, what can Android kind of learn from embedded Linux? Well, I think that Android, you know, the reason that Android was positioned at the right place at the right time was because quite frankly, in the embedded Linux space, we couldn't make our mind up as to what the UI looked like. You know, is it cute? Is it GTK? Is it, what is it? If you can't figure out what the user experience is going to be, you're not going to be successful. You can't really master it with something. And so Android was at the right place at the right time with the kind of user experience and quite frankly, taking into account the skill sets that are available from programmers coming out of school today. You know, the universities aren't teaching people how to work in reduced footprint environments terribly well. So, as far as they're concerned, CPU cycles are infinite, memory is infinite, storage is infinite, and everything has a swap. Everything has a swap and everything runs in a VM. So, Android is perfectly positioned for that kind of mindset. You know, it's interesting you bring up the UI thing because that's something which, you know, has been kind of challenging, I think, when you think about, you know, you've got a big iOS ecosystem of app developers that are not, you know, using Java, right? And that's, you know, you've got the Android app ecosystem. And then, you know, there's an emerging piece that I think, I don't think that the final page, I don't think we should close the patent office on that one yet. Oh, no, no. Because one of the things I think is real interesting to see is some of the developments with HTML5, as an example. And so, that has a kind of a real potential, I think, to be very nice cross-platform sort of capability for app development, for UI development. So, I wouldn't necessarily think that doors closed on that one. One of the things I think is very, that we've tried, you know, when you think about kids coming out of school, a lot of them are actually learning C++. So, QT is actually a very interesting alternative. A lot of kids in other schools are coming out really involved with Linux. And so, the whole GNOME, GNOME mobile areas, very powerful, you know, what we've tried to do in the Octo project is trying to support all of them. And that said, okay, this is the one way you gotta do things to get the best sort of support. We've tried to bring the best of the community in, so you can develop applications on the Octo using QT. And I got a really great C++ guy that's on board maintaining that stuff, right? We've got people who are, and the HTML5 thing, I think, is incredibly powerful as well. We're gonna have a talk this week, actually, on some digital signage things based on HTML5, which, in theory, you could replace with a number of different OSs. But I think that sort of captures that kind of investment that I think will be there going forward. So, you know, you're right. That is a powerful thing from Android that I think positioning Java from that sort of sense. It's interesting to see that 20-year-old technology get a breath of fresh air a little bit. So, we'll sort of see how that materializes. The future of Java in general has me a bit concerned at this point. When we look at Oracle and what they're doing with Java and we're not doing, you know, they've got a lot of security holes that they're not fixing, you know, is the Java ecosystem then going to transition to just what you can do on Dalvik and Google takes the reins of that. You know, where does the open-source community come into play in the features of the language and keeping it moving forward? Or does Java become the next cobalt? Zach, you want to take a stab at that? Cobalt, maybe Fortran. Maybe Fortran is still alive and well. And cobalt is alive and well. Actually, I heard it's horrible. I hear if you are a cobalt programmer in the financial district in New York, you can make a lot of money on ticket shoes. So what do you think Zach can do? I think that Embedded Linux, I actually think Embedded Linux has nothing really technical to learn from Android, but I think it has some things, some higher-level things that it could learn. One, the first priority is that the highest priority is the ecosystem. Being able, and not, you know, Linux developers and things like that, that ecosystem will survive no matter what. Sure. It's the ecosystem of app developer to user. Sure. And the second priority is how do I reduce the time to market to take widget thing in new SoC thing and connect app developer and user? If I can get that down to where we're currently at at the Android space where you can pretty much turn an Android device in the time it takes to build a slide deck, then we're ready to go. And I think the third thing is that existence proofs are very big and being able to take a system that has seen a billion users make my little change and insert that into that ecosystem and know that I'm gonna be okay, that's huge. Right. Nobody, people use Android because it has worked in the past and it's will work in the future. And whether Google goes bust or whatever, I mean, it's kind of irrelevant. I mean, that's like saying if Intel goes bust. It could happen. I mean, it could happen. Intel? No, it could happen. I hope I'm time dead by the time it happens, by the way. My children, I hope I can get that through college. Right. That's my hope. But yeah, we'll entertain that idea. I mean, Android is not, Android's a particular solution to the problem of delivering a service from somebody wants to create it to somebody wants to consume it. And it's just a very effective and efficient way to do that. I don't think you can underestimate the paradigm shift of the App Store or iTunes, whatever. I mean, try to go into a prize or a Best Buy Today and buy software. Right. You can't. You don't sell it. It just doesn't work. Right. So, but by that same token, you have to understand that that has also changed the model for what people are willing to pay for those apps. Yeah, sure. I mean, if Microsoft decides to sell Microsoft Office on iOS, they cannot charge $500 for an app. People aren't willing to pay that. They're down in the area where they're saying, well, I'm willing to pay maybe $15 or $20. Right. So, it has completely changed the monetization for how app vendors can then sell things and the prices that they can expect to get off of those apps. Makes sense. Makes sense. And I was wondering if I could get your take on the licensing in general. So, one of the things that Android did was kind of like start from a clean slate, if nothing else, for licensing reasons. So, whereas the traditional Beto Linux stack that we're used to has a lot of GPL and LGPL components, the Android stack is mostly based on BSD and Apache. Do you think that has benefits and pros and cons? What are the pros and cons of having happened essentially? Okay. So, it does have an effect on how companies perceive their responsibilities relative to the open source community. And without going into specifics, I know of companies that when they make out their, when they go through their GPL obligations, they go through their license obligations. And quite frankly, I don't know if anyone's ever done this, but when you ship a product, a modern product, there's a spreadsheet that goes along with it that has the license for all the different components. And I know Yachto's working on SPDX and there's, but it's a thorny, big thorny issue. And currently, I know that companies, when they see the BSD license, they are happy about that, but they also, it doesn't compel them to push stuff upstream or to publish it. And I do worry that it ends up, there's a lot of good changes that are being done by companies that are not getting published because of the license. And so it's a concern going forward. It's hard to say, you know, you don't know what companies are doing. And so you don't know how much of technology is getting lost or not shared. You know, it's an unknown, but it is a worry. Yeah, I mean, Tim's right. A lot of what we're doing, the Yachto project is trying to be, because there is so much abuse of licenses actually that are going on and embedded, I think there are a number of companies putting out devices where you can't get sources for the GPL, even the, you know, kernel batch, right? So what we've really been trying to do is be kind of an example setter relative to, you know, if you produce the image, you can also produce the complete source archive, you know, also have the complete, you know, license manifest. So you can generate those things automatically. You know, some of the, and I think GPL has been pretty powerful for to build the community effect. And I just think about operating systems that have been based on BSD in the past. BSD is one of them, you know? And we see where it is now. I mean, I got my start on, and my first Unix was 4.2 BSD on the Vax, right? So I, you know, there was a lot that I kind of remember from that era, but it's like, you know, it's the multiplicative effect haven't been there. Now the other piece of, you know, that had been worrying some people as GPL version three, you know, as because of the changes there, I'm a, you know, strong advocate of the GPL and all of its versions of flavors, but some people have difficulty because of the anti-televisation, you know, factor in GPL v3s. One of the reasons why we build a version, we can either have GPL v3 or not, it's very easy to put a one line in the configuration file or a checkbox on the UI and say, build with no GPL v3, and that we're able to produce that piece, which comforts some people, right? So that's, you know, I think we're trying to, I think the community effect that what we're doing with the OctoProject has really, you know, dealt with some of those license issues, you know, that any concerns that people have, and I think there's a lot of success that people have. Well, but I think that by that same token, you see that there are many cases, for instance, as somebody who works with customers to build new devices. Right. If I wanna build a new device based on say, OMAP4, and OMAP4 has that PowerVR graphics chip in it, and if there's any problem with a codec or something that's not playing nice with that PowerVR graphics chip, I'm screwed. Yep. I can't get access to the source, I can't fix it, I have to tell the customer, sorry, your codec just isn't gonna work because the guys at PowerVR aren't cooperative enough to be able to give me enough information to be able to fix your problem. So I think that there is some impact of people hiding behind the BSD and the Apache license to keep you from being able to do the job you need to do. Not that they're deliberately trying to keep me from selling product, but then I understand. Zach? I think licensing issues are kind of a red herring in the whole discussion. Okay. I think that market pressure will trump any licensing issues that people actually run up against. And if there is a economic incentive to use a GPL v3 component, it will happen. Because at the end of the day, that, you know, the ability to ship product overrides those things. And in fact, I'd say that very argument is what brought Linux into embedded anyway, which was the economic incentive to not pay licensing fees or to be able to have access to the source was so strong that companies who would just say, this is our IP, we developed this, would forgo that in an attempt to beat their competitors to market with something. And I think what we see is we see, I'd say in five years where, you know, software, software is going in the exact wrong direction to Microsoft wants it to go. It's become everywhere. And that's been, that's a win for the open source world, right? We may dicker about licensing and SPDX, you know, you can go through and do the full analysis of, well, does this license preclude this license and so on and so forth. But at the end of the day, I think companies are finding that they sell, they can make more money producing services as opposed to software. And so I think what that does is they say, well, we don't care, release the source. You know, there's no IP in there. All the cool IP that we did, we squirrel that away in the chip. And so I think you see, I mean, for good or for ill, what you see with the GPL is you see, essentially the GPL caused all the fun bits to go into silicon. Well, you know, just take the point that I think in graphics is a perfect example of how that's not the case, right? And that's a real struggle that people have had. I think actually, you know, some of the AMD and Intel graphics chips that are finally have open source, you know, drivers as examples out there have shown that a lot of times there's a laziness factor that goes into, you know, I'm designing, I have this co, what do you call it, incestuous, you know, between incestuousness between the low level hard software and hardware designers and things of that sort. So there's a certain amount of struggle there. The reality every one of us live with though is the fact of that, as you said, there are closed source graphics drivers out there that make it extremely difficult. Both both. Yeah, okay, you know, you're right. You're right, it's a challenge, you're right. And so they exist as a factor. And you say, if it's economically viable, right? Well, that didn't really help the little guy. If they're the little guy or gal who's trying to make their living based on something, well, it's not economically viable for me to go and obviously address a customer's needs. So they gotta go to somebody really huge. It seems like that's kind of incredible. So I actually think there are strong motivations. You're right, Zach, as there's a strong motivation, I think, for free software to really help a lot of businesses to do amazing things. And charging for software doesn't seem to be as strong of an issue. Although being able to charge for services, for support for a lot of those capabilities, I think, is pretty powerful. All right, cool. So if we didn't kind of address the question of a replacement of Embedded Linux, how about kind of having them coexist? Is there any value in a developer actually using a classic Embedded Linux stack side by side with an Android stack? Absolutely, absolutely. I've done it both ways where I've had a Linux cheroop running side by side with Android. I mean, the key is the kernel. As long as we have the kernel and the kernel is the same, then I can mix GPL or LGPL libraries, squirrel it off into a sub-directory someplace, and then run Android right side by side with Linux. I've also done the other thing where I've got an Android piece on a Linux box. A Linux box boots up and does all of its hard or softish real-time things. And then we use Android as the UI. You can do both. And you can counter mix. You can mix them and mangle the two of them together if you understand the overall architecture for both of them and how they overlap or don't overlap as the case may be. I think running Android in a VM is another option. Since virtualization is now becoming more and more of a reality with a lot of chips, I think running, in fact, someone was telling me about, oh, you could run their automotive system, put the Android games in the back seat. You're running on a VM, but run the critical car systems on a Linux basis. There's at least one company I know of, and I may be getting the name wrong, but at the risk of being the name wrong, I think it's open mobile. It has a product that will actually be Android application compatibility running on Linux. And I think they're doing, I'd love to give props to them. I don't really know them well enough to know, but I think they're probably going for market access. So like you were saying, the app ecosystem piece, which I don't think is actually that relevant for most embedded applications. So maybe you just want the UI, right, and those sort of things as opposed to the full Monty. I want angry birds when I'm doing the laundry. OK, got it. My wife. Yes, of course. You will do the laundry, so I might as well be your thing. Might as well do, yeah. Yeah, I think one of the points regarding to the APIs is the access to a developer community of people know that API, not so much the app itself. Well, it's also the tools, right? Yeah, and the tools are pretty good. Right, the tools are pretty good. Yeah, I like what they've done just recently, where they bundled everything together, one download, you get Eclipse, you get everything all nice and packaged. Yeah, absolutely. It's a huge benefit over every baby that I have. Zach, you want to take a stab at that? Yeah, I would hate for a traditional embedded Linux to go away. Because traditional embedded Linux is how we develop. I mean, it's how you need Busybox, you need a more capable general purpose system to be able to bootstrap Android in a lot of ways. Anybody who's tried to sit down and do kernel development in an Android platform will tell you, it is not going to work. We need all of our tools. Where's our tools? Where's our, you know, and I mean, Barrow has kept the, from Lunaro, has kept this great Per for Android patch set going for a while. We're trying to get that upstream. It's just, you know, embedded Android is a lot, or embedded Linux is a lot of fun. And it's an extremely useful way to put together systems. And I think that as embedded, I think at the core of the argument is, it's not an either or thing. And that unhealthy ecosystem rises all, all boats rise, right? Absolutely. So I think that it behooves, I think it behooves everyone to, you know, work close together, you know, kind of say, you know, I mean, we're all competing and we're all cooperating. And it's this great world where we live in where we're able to do that. But at the end of the day, we're all running Linux. Right, right. And which gets me kind of like the last question and we're kind of short on time here. So I'm gonna ask you to make it quick, even though it's the most important question. So you ever see a horizon where Android would completely wipe embedded Linux out of the map or at least the embedded Linux that we, as we know it? No. No. No. Jack's looking up. Quick enough. Jack? Well, he gets the last word. I'm gonna make this point. One thing I kind of go back to people that, before the invention of the Loom, right? You had artisans that would craft textiles. Right. Well, the Loom standardized how you created textiles. Android standardizes how you create software components. And now we're kind of entering this new world where we don't do so much software engineering as we do software manufacturing. Okay. I think that embedded Linux as it is today will become less and less viable as a way forward. And I think Android has introduced that so that the traditional person sitting down, putting their platform together, packing it together and putting a product out, I think those days are either gone or they're numbered. You could be from Microsoft saying that. Yeah. Yeah. I'm sorry. That's true. That sounds like exactly something you'd hear Bill Gates say. Sorry, that's really a little bit like, you know. Well, yeah, I mean, from my perspective, I wanna be able to still run on top of an ARM 926. You know, an L138. I wanna be able to use our PC. ARM M3, so. Yeah, Cortex M3, you know. 8088. There's a lot of requirement. Cortex M3 is never running Android. Well, okay. That's good. That's gonna be a Bill Gates quote, right? That's right. Okay, that's cool. So we're kind of very short on time here for questions, but I'd like to see if we can get one or two questions. There are mics in the aisles here if you can just get up to the mic if you have any questions for our panel here. Or not. Okay, well thank you very much. Oh, there's one question. All right. I'm sorry, you're gonna have to grab the mic. You see there is a need to define what is an Android system from hardware perspective. You know, if you're gonna deliver the apps that run on any Android platform that depends on say, BLE being there, or depending on what Mike was talking about for accessories that your device should be supporting USB hosts. So is there, do you guys think there is a need for defining what an Android system from hardware point of view is? I mean, we have defined it from the software API, but we haven't defined it what. From a means to the public standpoint. I think the CTS pretty much describes, if it doesn't run the CTS then it's not going to be Android from that perspective. But when you start talking about putting sensors out there that's always gonna be, that's not a generic device. That's not a generic Android device. You're tuning it for a specific application. And once you start doing that then you basically don't have the ability to run it on everything. One last question, any takers? There's one over here. The original Galaxy Nexus only had two binary blobs, one for the graphics and one for the radios. The Nexus 7 has six and it seems like a alarming trend where you have more and more and more binary blobs. I was wondering if you could comment on that. I'd like to comment on that. So one thing I, first, I think most people in this room owe a big debt of gratitude to JBQ from Android who by and large keeps AOSP going and enables a lot of this to actually happen. Android's an interesting ecosystem even within Google. JBQ has always said, I hate binary blobs. And but the SOC vendors say, well, I wanna protect my IP so we're gonna ship with binary blobs. But if you look at Nexus as a platform the goal has been to have a zero binary blob build. And if you look at, I believe it's the, which one is it? The Nexus 10, I think if you look at the, no, it's not the Nexus 10. But anyway, the goal for JBQ is to have a completely open device. And that's a good goal for the person that is releasing all of the software and is a real driving goal or force behind that. So yeah, I think it's like it's just Google is having to deal with how the SOC manufacturers wanna deliver their enablement. All right. Well, thank you very much folks. Thank you guys and enjoy the day. Thank you.