 So the last talk was pretty interesting because I'm going to be talking about similar things. And one of those jerks in the audience who was like, yeah, it takes me five days to build my root file system. And it also takes about 30 gigs of hard drive space. He didn't mention that part, which when you're doing multiple builds, that adds up very quickly to a disaster. So I'm Ken Gilmer. I'm from New York, and I have this thing called the bug. And it's an open source hardware and software platform. I was just talking in the embedded room an hour or two ago. So if you thought that talk was useless, this talk is probably going to be even more useless than that because I only have 15 minutes. So I'm just going to talk a little bit about the device and tell you what it's about. So this is it. It's hard to really see, and this microphone feels like it's choking me somehow. It's very claustrophobic. But essentially what it is is an ARM-based computer similar in a way to an open moco phone, except it's not a phone. I use this similar technology. It's an ARM CPU, 128 megs of RAM. We have a Linux 2.6.27 kernel and a root file system generated with open embedded or more appropriately Pocky Linux, which is a subset of open embedded. And it's all boots off an SD card. We use RedBoot and this kind of kexec hop from one kernel to another to get onto the SD card. And we have a set of modules. Currently we have about six or eight shipping, and they do various things. This is a touchscreen LCD where you run Matchbox and some GNOME mobile apps. We have this thing called the Von Hippel module, which is a breakout for various hardware experiments. You have a specific component. You'd like to integrate into a Linux, a portable Linux device. This is a very kind of cool way to do it. I'll talk a little about each module in a second. So the kind of, the idea for bug is we're trying to let a different kind of person use embedded systems or build their own devices. Typically from my understanding, when you want to build your own hardware, it's very difficult. I certainly couldn't do it. I'm just a mild man and software developer. But there are people out there that can do that. But if there was more people that could build devices, then I think maybe we would have some more, even more interesting applications. And open source would get into even more kind of nicks and places. So we've built the device specifically to make it easier for people to build their own gadgets. We've created APIs for each of our modules. So for example, for me to take a picture, it's one line of code in Java, or I can call a web service, or I can use Ruby to use a URL to get that image. So the idea is simply there is we want any kind of developer with any language constraints to be able to use the bug, not just C or typical traditional embedded development technologies. And with the module idea, the idea is you can create devices that normal consumer electronics companies would never build because the market for those devices is just too small. So if you take maybe an FPGA and a camera and a Geiger counter, maybe you could create an application that's really compelling for 1,000 people, but that device would never be generated by a normal company because it will not make them money. So maybe that's kind of confusing, and it's hard to really pin this down. I agree. It's confusing. But I think it's going to be hard to really talk about it in 15 minutes. But I think the core thing is that we're just using Linux, we're just using Java. We're using standard technologies that people already know. There's no magic. We don't have any proprietary interface or super secret APIs. We try to do everything we can with existing standards. The one area where we don't follow standards is typically our APIs for the hardware. There are some Java APIs that are kind of standard, but a lot of them are not open. So rather than trying to open not only a sense of code, but open in a sense of the team that's working on this GSR is what their status is, what they're working on, when things are going to be done, those kinds of processes are also closed. So rather than try to fight that war on multiple fronts, we've just decided to use our own APIs at the Java layer. And in certain cases, we have open source stuff we also bolt on. One example of that is a mid-path project, which has some sound and some mid-P technologies for Java. So our sound module supports audio via mid-path. So I think a good example of a very simple application that people might use or want, but just doesn't exist today, I think, well, it's hard to say, but maybe like a GPS alarm clock where instead of waking up at 8 AM, you want to wake up when your train is at the train station where you get off to go to work so you can sleep all day on the train. There's really, it seems like more that sensors and hardware technologies drive interesting innovative applications versus just a general purpose computer. So here's a picture, maybe a little better than what I have right here. The top one is the good thing you'll find on our store. This is the von Hippel module with random things plugged in. I'm sure that doesn't work. It was just for the photograph. But it kind of looks cool. I mean, it's kind of that giant switch. Come on. Who's going to do that? That's ridiculous. So we have these modules here. We have basically free ZigBee. It's not ZigBee because you can't call it ZigBee because it's not open. We have a radium modem that does the same kind of thing. We have GSM data, GPS, again, the von Hippel touchscreen, and audio. We have an SDK based in Eclipse. So if you want to write some plugins in, or sorry, some OSGI bundles in Eclipse to write apps for a bug, it's very simple. We manage the class path for you and we give you all the Java docs and the APIs. If you want to do it in Python or OCaml or Snowball++, you're kind of more on your own there. We support a lot of tool set for Snowball yet. Again, it's 100% open source. So like on the SDK side, we're at EPL because it's easier to use their license and on the bug, naturally, Linux, it's LGPL and BSD. So some specifics about the hardware. I would like that hackable, is that guy still here? Marcus is still here. I'd like to talk to him later and maybe we can get the hackable distro on the bug too. But it's got some, you know, the basic ARM architecture. We have USB on the go, so you can plug in a keyboard or you can attach it to a computer and do networking through USB. Like he said, two gig SD cards are super cheap, so we have this build that after 24 hours and 30 gigs takes about 100 to 120 megs uncompressed on the SD card and that includes Java and all our application layer as well as a full Linux distro based on Pocky Linux with matchbox and what you would come to expect in any kind of modern Linux system. It has a Linux, sorry, it has a battery. You can't really see it, but it runs the full length of the device and the power can last from an hour to five to 10 hours, depending on what you're doing. And it's hard to see, but there's this connector here. It's a Samtech connector. It's a kind of a standard part. We didn't make it the intention being that anybody should be able to build their own modules, not just the ones that we provide. So as an open platform, we want users or people just to customize it themselves. And that's the whole reason why we open source the hardware as well as a software to just make it completely obvious to people that we're not trying to lock them in anything and that the platform as a whole is more interesting when it's open. So this is from our wiki. This is a screenshot of the connector. And we have these pins. It's kind of hard to see. But you might see here is this USB serial I squared C. They're just kind of standard interfaces. Essentially all we've done is taken the pinouts from the MX31, which is the CPU we use, and exposed them on this connector. In some cases, we have some multiplexing going on. We have an additional USB host controller bus for each module port, so there's four. And I think there's some stuff going on with serial. We have a serializer for the display so we can press a bunch of signals from a lot of pins into very few so that we could fit more interfaces onto the connector. But in general, if you have some kind of existing sensor that uses maybe serial or some kind of common interface, it would be fairly straightforward to integrate that sensor or piece of hardware onto a module and then you would have kind of your own custom gadget without having to build the entire thing from scratch, which we think is pretty sweet. So just a brief overview on the modules. This is a camera. We're not shipping it right now. We're not shipping to Europe at all, so I mean, you're just seeing this, but it's not going to blow anybody away. It's kind of a standard cell phone camera. But one of the cool things is like I said, this line of code takes a picture. That's all you have to do. I mean, we have to do some OSGI stuff, but it's pretty straightforward. So I mean, we're trying to make it very, very simple for people to use hardware and gadgets. So we tried to make everything like play an audio file, take a picture, get my location, reduce it down to a very simple amount of code, and then expose a bunch of stuff in the background if you want to get fancy. But if you want to do something simple, then it should be simple to write. Here's some more. So this is Java code. This is to open a window. One of the funny things is we're using QT for the budgeting and the JVM because there's no GTK support, but we're using Genome Mobile as the desktop. So it's kind of a Frankenstein kind of system currently. GPS. Again, there's this one line of code for getting your longitude and latitude. There's no magic. You just get some big numbers and you have to figure what they mean. A cellarometer. So we have this guy right here. Looks kind of like a big I, but it has a three-axis cellarometer, and you can get your forces and do some interesting things. And audio. It can play an audio track that doesn't currently support audio in from the Java layer, but you can do it at the Linux layer. And as I said, the Von Hippomodule, I won't get into the specifics of this because I don't really have the time. But again, plug things into it. LEDs happen. It's pretty, pretty sweet. So these are some things we're working on that I wouldn't say necessarily I've got to the point where we're really going to make them. But ideas for additional modules or hardware to make the bug platform even more interesting. I think that the modules I've shown you today, by themselves are kind of cool. But none of them are like, oh, wow, that's totally a new kind of thing. I would never be able to do that. So I have a camera, I have an LCE screen, I have a motion detector, or a cellarometer. I have that stuff on this too. So it's not really that compelling. When you add a Geiger counter to the mix, then you're never going to have an iPhone with a Geiger counter. It's just never going to happen. Steve Jobs is never going to get in front of a bunch of people and be like, one more thing, Geiger counter on the iPhone. This won't happen. So that's kind of the power of the bug. As a platform, you can add hardware that no one would ever think to add. And you can build applications that no one else would be able to build all open. So a little bit about the platform. Red Boot, Linux, Pocky, the standard GNOME mobile stack. On top of that, we use Phonemy, which is our Java JVM from Sun. It's a GPL. And it is designed for ARM devices, runs very fast. I think when we compile, the whole JVM is like a meg, or 1.5 megs. So some people kind of react to Java like, ah, it's so big and slow. But really, Sun has done a very good job of reducing down things to keep it light, fast, and generally usable on a small device. And on top of that, we use our Cloncierge OSGi one time. So we have this kind of embedded system computer, but we're trying to solve problems that are more in general computing kind of idea. So in a typical scenario for embedded systems, you kind of know the system. You link your software directly to the hardware, and you assume it's always going to be around. And in general purpose computing, you kind of applications have to share resources. And you have things like window managers and daemons for GPS. So we had to kind of take things from the embedded world and the general purpose world such that applications on the device would be able to run together or not collaborate with each other. So OSGi is a way of solving that problem by letting different applications access resources through what's known as the service registry. I don't really have time to get into it, but it's definitely an interesting technology to check out if you're not familiar with it. And then RSDK, we have a virtual bug. It doesn't look very good. And it's hard to make it look good, because we have to support Windows. And Windows is really hard to support. But essentially, you get the APIs, and you can play around and see, is it really? Can I take a picture with one line of code? And obviously online, but it's almost one line of code. The RSDK looks like this. If you're familiar with Eclipse, we have some web content. You can see applications that people have uploaded, comments about what they've done, rate them. It's kind of like Flickr for weird mobile applications. It's all available online. You can check it out. And it's called BugNet, but really the URL is buglabs.net. It's kind of confusing. But you can go there and see firsthand what people are writing. So this is kind of a screenshot from a last week. And someone did a GPS logger and a map application. Some of this stuff is mine, actually. But you can get a sense of what people are working on by just going to the site. And that's it. I have one minute, if anybody has a question. Yes? The price is, we have a store online, but the base is $249. And modules vary between $40 to $120. And we're working on getting shipping to Europe, hopefully this month or next month. Yes? Bug stands for, Peter, what does bug stand for? Peter in the back, he's the one who coined the acronym. That's classic, Peter. Didn't really answer the question. He just said something else. But there's really no definition for the acronym. And I'm out of time. Thank you very much.