 Welcome, this is the Freedom Box target support, and Nail Garby. Okay, thanks much. Is the sound working okay? Excellent. So, thanks everybody for coming this afternoon, and I suspect that we've probably got a fair number of people watching via the streams and other places. Welcome to all of you as well. What I want to try and do this afternoon is give you a little bit of a sort of background and context about this thing called the Freedom Box Foundation. And because this is the Debian Developers Conference and there is a very close relationship between the activities associated with the Freedom Box Foundation and Debian, I will try to focus a little bit on what the relationship between Debian and the Freedom Box Project is and how all of that should work. Out of curiosity, how many of you have already had the opportunity to either be present in person for or to watch one of the replays of one or more of Evan Moghlin's talks about the Freedom Box? Very good. Okay, how many of you are here because this seems like an interesting title, but you really have no idea what we're talking about? Okay, cool. That's fine. I feel like maybe I've hit the right balance in the presentation materials today, though we'll see how that works out. Okay, so what is it we're talking about? Well, the vision of the Freedom Box Project is this notion that the current way we interact with each other through the Internet using the highly popular social networking technologies of today is a way that involves giving away too much of our information, making our privacy suspect and, in effect, giving too many other people a say in how much freedom we actually have. And that if we could only take the free software that we have all worked on and continue to work on and which is core to the Debian Project and other related things and bring it together in a reasonable configuration that is easy for people to do the right things with, that we could have personal servers running a free software operating system and applications that were designed to create and preserve personal privacy while allowing us to participate in the kinds of social interactions that all of us want to be able to participate in on the Internet. And another element of the vision, as Evan has articulated it, is this notion that it would be really nice if that kind of a software stack could run on these cheap, power efficient plug computers, mostly based on ARM processors, they're not exclusively, that are small enough and inexpensive enough that individuals could buy and install these and run them in their own homes. The in their own homes part has a special value in this particular context because of the different legal protections and many jurisdictions that are available for things that stay within a personal residence as opposed to, in effect, being given away in the process of installing them on equipment that runs somewhere else. Another sort of core idea behind what we're trying to do is that we want to be able to contribute to this concept of building privacy respecting federated alternatives to contemporary social networks. You've all heard about projects that exist in the world today to try and create alternatives to things like Facebook or Twitter or YouTube or whatever. We don't necessarily expect to build those solutions, but we would love for the Freedom Box platform to be one which can help people to build these sorts of privacy enhanced, privacy respecting federated alternatives, distributed federated alternatives to current contemporary commercial offerings. Another thing that comes up over and over in the process of talking about Freedom Box is this notion of the importance of mesh networking. Regardless of how you actually feel about sort of the current state of readiness of the various mesh networking protocols and so forth, it's clearly the case that in many of the potential use scenarios for something like a Freedom Box, one of the things that's important is to be able to augment or replace existing infrastructure. You know, maybe that's because you're in a legal context or an economic and business context where the ISP you're dealing with wants to control your ability to access some particular site and being able to share a connection sideways through a neighbor friendly neighbors system who's using a different ISP and to trade that kind of service back and forth with each other would allow you to have some kind of response to net neutrality problems. Or perhaps it's because you're in the middle of trying to organize a protest somewhere and your government has turned off your internet and you're trying to figure out how to reestablish some kind of infrastructure and connectivity. But regardless, this notion of mesh networking and good routing capabilities in the box is reasonably core to the way we think about this. And then finally, if we can bring all of these things together in the long term, we hope that the solutions we would build would help to facilitate collaborating safely and securely with others in building social networks that are capable of being used to support protest demonstrations and mobilization for political change. Because in fact, there's very little distinction in our minds between freedom in the software world, freedom in the network world and the rest of the freedoms that should matter to all of us and that we see our friends and colleagues around the world trying to fight for. So why Debian? Why is Debian such a good fit for the freedom box activities? I suspect that very few of you in this room have any trouble thinking of, you know, a common set of answers to these questions. But when I talk about this in other places, and when people watching the stream from elsewhere who are not as familiar with Debian think about this question, I don't know that it's always so obvious to them. You know, some of the core values and core structural elements of how Debian is put together and how it works are just absolutely perfectly aligned with the way we think about how software should be developed and evolved for something like the freedom box. Completely open volunteer organization with a very intense focus from the very beginning on freedom, a very strong technical infrastructure. Debian is at the root of a very rich ecosystem of derivatives, some of which are represented by some of you in this room. It's also quite international. Because there's no particular company behind Debian, it's not just the case that it's all volunteers, but we are volunteers in many different countries. And nowhere is this ever more evident than when we come together at a DEB conf and you get the chance to walk through the halls and listen to people collaborating with each other with many different languages and accents and cultural, social and economic backgrounds all coming together to make great stuff happen. From a technical standpoint, the fact that Debian runs on a broad variety of hardware means that what people have available in different places all can be brought together and used effectively to create freedom boxes. And there is this sort of maxim that I love to repeat that because of the inclusive nature of the Debian project and the willingness of Debian to accept new developers and new package maintainers and new volunteers of all kinds, all free software eventually ends up getting packaged for Debian. And in fact today with the vast number of packages that already exist in Debian, many of the things that we need in order to construct a freedom box software load already exists and already packaged in Debian. So if we flip this around the other way, why should Debian care about freedom box? Why is freedom box interesting or important? Well, first of all, I think many of the people who are interested in the freedom box project who are also Debian developers just feel some kind of connection with the goals and objectives of the project. It's not surprising because I think the objectives of the freedom box project align well with Debian's own. Debian has always wanted to have good security, to have good support for cryptographic work. We went to quite some effort a few years ago, for example, to obtain the legal opinion in the United States that was required to allow us to incorporate good crypto software in our main archive and to be able to export that from servers that are hosted in the United States. And that allowed us ever since and forever into the future to have Debian be a distribution where strong crypto is integrated in all sorts of reasonable ways through the distribution. There's also this, I think, immense and growing public interest in this concept of the freedom box. Specific instantiation, I don't think many people who are in this category really understand exactly what we're talking about. But there's a growing sense of unease about the extent to which information that is put out into the cloud, into some commercial servers, services, servers somewhere, ceases to be under your direct control. And as the media and various discussions continue to grow outside of the free software community, there's an opportunity for us to take advantage of this growing public interest to bring more people into the ideas that are fundamental to us in the free software world. And I think it really can demonstrate the values and I make that plural specifically. It's not just the value of Debian, but Debian's core values can be demonstrated in the process of building and delivering the kind of solution that we're talking about. Okay, so that's sort of a quick overview of what the vision, the concept, the idea behind the freedom box is. Now let me talk just a little bit about the foundation, the Freedom Box Foundation. So the foundation was created earlier this year and only recently actually sort of completed the process of legally coming together as a foundation. It's not a big organization in a style that's very reminiscent of and very compatible with most free software communities. The foundation, you know, it's a big name with a really small group of people that are passionate and dedicated trying to make things happen within that context. The foundation was founded by Evan Moglen, of course, this is an attempt to instantiate a vision that he has articulated and that many others have contributed to enhancing, expanding and collaborating with. And of course, you know, an important moment in history for me personally and for many others in this room who have chosen to participate was his participation and presentation a year ago at the Debian Developers Conference in New York City, where he issued something that sort of amounted to a call for action for people in Debian who felt similarly to come together and try and help make something real happen. A foundation needs to have some kind of organizational structure. In this case, we have a board of directors that's responsible for the operation of the foundation. There are three members of the board at the moment. Evan, as the founding sort of board member and ostensibly our chairman of the board. I'm a member of the board and Yechai Benkler is the other person who was recently announced. It's a good mix. We have a lawyer, we have a social scientist and we have a technologist and the three of us so far are having no problem communicating and coming to decisions about things. In recent weeks, we also announced the appointment of James Vassili as the executive director of the foundation. He's a lawyer who's been associated for a while with the Software Freedom Law Center and is immensely passionate about all of this. The challenge that he faces, of course, is that as executive director of a foundation like that, his primary job is to take the mundane, boring, behind-the-scenes foundation work and turn this into stuff that seems exciting and newsworthy. And I wish him the best of luck with that. I will talk a little bit more about the technical advisory committee that we've put together. One misconception I would love to correct immediately is the technical advisory committee is not like a group of technologists who intend to do all of the work. It is rather a group of technologists who are capable of observing the work that's going on in the community and helping the board of directors understand what's happening, what pieces of technology are interesting, what trends we should try to assist with and what things we should bring together. And in the end, this is where recommendations about exactly what things should be part of the reference implementation will be reviewed, vetted, and any decisions that have to be made will occur. And then recently, actually only about two weeks ago, we began the process of instantiating some official working groups, if you will. The set of those is not yet defined. I'll have a little bit more to talk about the working groups here in a few minutes. So how do we think about the work at the foundation? The first thing to understand is that the foundation does not intend to do all the work. It doesn't intend to take away the ability, the authority, or the responsibility of every free software developer who's working on a relevant piece of technology from doing the things that they know they need to do. Rather, this is about doing all of those things that won't magically happen just because free software developers all agree that something's a good idea. And when we think about it, we have sort of broken this down into four areas, categories. Evan likes to refer to them as the four pillars of the foundation. And those are technology, user experience, publicity and fundraising, and industry relations. I think the technology one is probably obvious. The thing that we think about the most is free software developers and packages and maintainers. It's the actual bits, the things that we will put on machines and run, choices about which protocols and which mechanisms for making things interact with each other. User experience. One of the things that becomes immediately obvious is that if we're not talking about creating lots of new software, that means we're planning to use lots of existing software or things that other people are already working on developing. But as all of us know, one of the challenges, particularly when we start to deal with software that has elements of strong security and cryptography and identity management and so forth, is you can easily find yourself dealing with software that wasn't really designed to be easy to configure. It's flexible. We've had a couple of other presentations this week that talked about specific challenges in different parts of the software that's available in W&W and around this. This notion that, gee, there's got to be some way to make this stuff easier to use. It's clear that if we expect people who are not as technically adept as we are to be able to take advantage of this software and put it to use in fighting for real freedom around the world, we have to figure out how to make some choices on their behalf, how to bring things together in a way that has end user comprehensible user interfaces and so forth. And so this is really a big deal. It's also an area that's had very little attention at the foundation so far. We understand that there should probably be another advisory committee with somebody kind of like the role I'm playing in the technical advisory committee focusing on user experience. We have not yet found the ideal person for that, though the search continues. Another area, publicity and fundraising. Unfortunately, in order for a foundation to be able to do anything that volunteers aren't spontaneously doing by themselves anyway, takes some money. And so part of what has to happen is a continuous background activity by the executive director and the other people who are involved in the core of the foundation to communicate what we're interested in, what we're trying to accomplish and to go past the hat and try and get sponsorship in various places. Industry relations. Maybe it's not immediately obvious to you what that means. That's the hardware manufacturer interfacing part. The reality is that if we want to be able to deliver a software stack like the one we've been describing on pieces of hardware that end users of various flavors could be expected to go by and deploy themselves, that's a piece of consumer electronics that we're talking about. It's not a random cast off PC in a closet. Yes, there are many smart people around the world including all of you in this room who I'm confident could go take an existing PC or an old notebook or something like that, load the software stack that already, elements of which already exist in Debian in which we will be defining and communicating as part of this project and achieve the kind of results that we're talking about. But what you would not be able to do as a consequence of that is go to a local retail electronics store and buy a freedom box. And that is part of the long-term objective that we have. It won't happen quickly. It's not even immediately obvious how some of the gaps between where we are now and what would be required for various manufacturers to be excited about producing cool consumer hardware. It's not clear how we get from here to there in all cases yet, but we believe that that's completely achievable and that it is part of the long-term vision. And in order to do that, somebody has to be willing to talk to hardware manufacturers, both the people who produce core elements of technology like the system on chip, parts that are at the base of these devices, and the companies who are willing to put those together into devices that they actually sell to end users. And in order to talk to companies like that, you often find that you have to be willing to commit to a non-disclosure agreement, otherwise they don't want to talk to you about anything that isn't already public knowledge. That's an unreasonable thing to expect a random free software developer to be willing to do. Who wants to deal with NDAs? Who wants to be in a situation where you can't talk about what you've learned? And yet, one of the roles that we think the foundation can play is to be that place where that interface happens, and in fact, as I'll report in a few minutes, the ability of the foundation to have these sorts of interactions with various hardware manufacturers has already generated some useful and exciting results. Okay, so the technical advisory committee. When I agreed several months ago to join the board of directors of the Freedom Box Foundation, one of the things that Evan specifically asked was, would I help to constitute a technical advisory committee and serve as its chair? And I said yes. The initial membership of the technical advisory committee is the folks that are listed here. I don't know that all of you recognize all of these names. Probably everyone here recognizes some of these names. Jacob Appelbaum, of course, is well known within the Tor community. Sam Hartman has been a Debian developer for a long time and is very well respected in places like the Kerberos community. And when it comes to thinking about the scenarios through which various security systems might be penetrated or broken down, he's the kind of person you like to have thinking about these things. Sasha Meinrath is very involved in the mesh networking world and brings a wealth of experience from that community to bear in this context. Rob Savoy, many of you will recognize his name as being a very long time contributor to FreeSoftware. He's one of the very early members of Cygnus Solutions. He's worked on tool chain and cross compilation and hardware support things for a long time. He also, more recently, is the person behind the Gnash project trying to create a FreeSoftware implementation of Flash and generally has spent an awful lot of time thinking about these sorts of issues and how various elements of software ought to come together. And Matt Zimmerman, many of you will recognize because of his past roles, both in Debian where he's still somewhat active and, of course, his participation in Canonical and Ubuntu and so forth. So as I mentioned a couple of weeks ago, James coalesced a conversation on the Freedom Box Discuss mailing list around this notion of working groups. People have been talking for a while about this idea that on the one sort of Discuss mailing list, there are a lot of different streams of consciousness that have been going on and it really could sort of be broken down into a set of parallel, all worthwhile and useful discussions. But we recently have run in a situation where it's very clear that some of these discussions among some of these subgroups on the Discuss list have become really annoying to other subgroups. And it's because people are trying to think about very different aspects of the project and coming at things from very different directions. And the way that we're hoping to take that enthusiasm and energy and harness it in directions that will be useful and not destructive is the creation of some working groups that people could subscribe to and participate in, each of which would be responsible for helping to design some element of what ends up being part of the Freedom Box Reference Implementation. All of those things would then be brought together and coalesced and become part of the whole. If it feels like I'm arm-waving a little bit about exactly what working groups are and how they work, it's because I am. We only started talking about this on the 14th of July, I think, on the mailing list and we aren't quite to the point yet where this is sort of instantiated and worked out. But it's certainly one of the ways that people who are interested in helping to contribute to the activities that the Foundation should pay attention to and think about because as these working groups form, joining one of those working groups will become, I think, one of the more straightforward ways to make a direct personal contribution to the project. And then, you know, there are other things besides just having a technical advisory committee and having working groups that have been happening. Some of the behind-the-scenes work at the Freedom Box Foundation that I alluded to a few moments ago is that when earlier this year, Evan and his team ran a Kickstarter campaign to raise some initial seed money to be able to afford to go start the Foundation to do the legal paperwork and the filings and get started, one of the things that they committed to was delivering some actual Freedom Box plug server hardware to some of the donors. And as a consequence, the activities kind of been going on to evaluate the available plug servers that are out there and pick one that would be a reasonable initial development platform. And the dream plug, which we have a couple of around and I have a photo a little bit later in the deck but just to give you some sense of what we're talking about, this is a dream plug with this little JTAG thingy hanging off the side. So this is to give you a sense of scale. That's kind of the physical size and shape of the objects we're talking about. That's a complete ARM-based server. And again, we'll talk about that a little bit more as we go along. But that's been selected as our initial hardware reference implementation platform and the plug form factor. And the problem is that even though it was sort of the best available choice, it's not perfect. And the imperfections come in various flavors. And one of the most egregious to us is that there were some source availability issues with the software that was being shipped by default for these devices. And folks like Clint and others and Ian Sullivan at the foundation have worked very hard on getting these things resolved. And they fell in the category of things like the user space utilities that are required to configure and manage the wireless access point enhanced Wi-Fi chip that's in these devices. It's sort of a frustrating story. As I say, one of our big remaining frustrations is that we have to deal with a binary firmware blob for that device for the foreseeable future. It's a little frustrating because it's got an embedded ARM processor of its own and there's clearly a lot of cool stuff happening in that firmware. I'm pleased that in some outline parts of the freedom box community, folks have gotten access to what seemed to be some very interesting documents associated with that hardware and how it works. And so there is at least the hope that at some point in the future someone might be able to write a completely free software implementation of the firmware for that device and that we might be able to move to that someday. But in the meantime, we have this binary firmware blob with some user space utilities that use APIs for interacting with that that are not the normal Linux kernel wireless APIs that we needed to have and didn't have. We also discovered that there were some missed features in the implementation of the UBoot bootloader that's in Flash in this device. And despite the license on UBoot, source code was not readily available, particularly the things that they had done to configure the bootloader for this particular hardware had never been pushed or merged back into the upstream UBoot community. And then finally, there's been sort of a history in the plug computing world of hardware manufacturers distributing pre-built binary Linux kernels. And the patch sets are usually available somewhere, but as has unfortunately been sort of the standard behavior within the consumer and embedded world, there's not been a whole lot of work going on to try and push all of those patches upstream. I'm really pleased that we've discovered that in this specific case for this device, an awful lot of the functionality that's been floating around in patch sets has in fact now been merged into upstream. And as of, I guess, 2639, something that we've been working with over the last week, we're down to a fairly short list of things that are still not merged into the kernel. But, you know, all of these things are annoying. And the reason they're annoying is I can't imagine anything more frustrating than building a freedom box based on free software and having elements of the software and the firmware that we're running that we don't have the source code for. It seems sort of complicated and backwards. But this is the kind of work that's been going on that has been aided by the willingness of the foundation to go have direct conversations with the hardware companies involved, to push them, to negotiate with them, to make things happen. A lot of the stuff is happening behind the scenes. It's not all that exciting somehow. I have to tell you, when we got the sources to U-Boot on the Dream Plug, I was pretty excited. And when they released to us the source code for the MicroAP user space utilities under GPL v2, I was also pretty excited. But, you know, somehow all of this stuff is, it's the stuff you have to do in order to go through the process of getting the right pieces together to build the solutions you actually want to work on. Another thing I want to talk about just for a minute, that's an example of the kind of work that the foundation has been helping to sort of coalesce and motivate already in a specific area is some work around what it takes to establish the initial trust relationships. I think it's sort of easy to intellectually understand that if you want to build a secure, distributed, federated network of devices, there has to be some way to establish the initial trust relationships between those devices. And when I say trust relationships, I mean if I want to share some documents with Daniel, you know, how do I know that the plug on the other end is his? How does he know that he's receiving those documents from a plug that belongs to me? How do we get those machines to initially know about each other? No matter what keying mechanism you decide to use, at the end of the day, it's the classic, how do you establish the initial points of trust and connection? We're kind of insulated from this just slightly in the Debian world because we have this existing really unusual and pretty cool web of trust that we build through our key signing parties and so forth around the set of keys that we use in our daily activities in Debian. But that sort of stuff doesn't really exist in the rest of the world. Even if it does, how do we establish these initial connections? As we've talked about this as one of the sort of real world end user challenges we have to have some answer for, we got really interested in this idea that almost all of the people who would eventually be users of this technology are likely to have some other devices commonly available to them, one of which is some kind of a smartphone. And today it's almost impossible to buy a phone that doesn't have a camera in it. I don't know if you've noticed that, but it really is getting to be almost true these days. And so what if we took advantage of sort of QR code stuff, you know, the same things that we were walking around with on our badges all week and had some mechanism through which people who physically met each other and made some personal association could take advantage of that device in their pocket to do something like exchange key fingerprints and then use those uploaded to their own devices as a way of establishing an initial set of connections and a web of trust between the devices. This is still very much work in progress, but Stefano Mifuli is working on that. And I think that as we go forward, this is the kind of thing that, you know, this particular piece of work was sort of inspired by a set of conversations we had within the Freedom Box Foundation and it's now led to somebody going off and working on a piece of stuff. And whether that piece of stuff ends up being hugely useful or not, the outcome of this work is certainly something that I will feel good about having helped to initiate. And then with respect to hardware. As I mentioned, our initial sort of hardware target for the plug-based implementation of a Freedom Box is this dream plug from global scale technologies. For those of you who aren't familiar with this kind of stuff, this uses an ARM-based processor from Marvell in a family called Kirkwood that runs at 1.2 gigahertz. So it's in the same general performance class as lots of other computers we use, but certainly not as fast as the notebook that I carry around. It's got a half a gig of RAM and two megabytes of an SPI attached nor flash for the bootloader. You know, all those magic acronyms, if you don't know what they mean, it doesn't really matter a whole lot. But in this case, the thing that's important to understand is that the bootloader, when we talk about U-boot and the bootloader, it's kind of like the BIOS in a PC. It's that stuff that has to be in some device in the plug in order for it to be able to boot and run a Linux kernel and get on with life. This particular device is interesting because it has an internal two gigabyte microSD card that's attached via USB, and that microSD card is big enough to hold a kernel and a reasonable root file system. And so it's entirely possible to think in terms of, you know, a device like this with nothing hanging off the outside of it as being capable of running an interesting and useful software stack. There's a lot of I-O on this device. It's got two gigabit ethernet ports, two, or at least more than one, is important because that allows us to think about putting these topologically into networks in a way that could potentially replace a router or a firewall device or, in some other way, possibly be positioned at the edge of a home or private network. There's also, as I mentioned, this really cool sort of Wi-Fi chip-on steroids from Marvell. It's in the same family as the part that was used in the OLPC and was the basis for a lot of the work that they did on trying to enable mesh networking stuff, so we're not starting completely from scratch there. There's a Bluetooth interface. There's a couple of USB 2.0 interfaces, an eSATA, which allows you to plug external fast hard drive stuff in. And there's one full-size SD card socket that, depending on which driver you're using, can actually be pretty good performance and a bunch of audio interfaces. I'm not entirely sure what we'll use the audio interfaces for, anything. Various folks have talked about the notion of, you know, running skypish kinds of voice connection things through here, but honestly, I personally think of that as being a better thing to do on a client device and not directly on one of these. But... I'm sorry? Oh, random number generation, yes. You could use the audio interfaces for random number generation. You know, gee. You could also plug a microphone in and listen to the guy on the other... Sorry, wrong talk. And for those of you who aren't in the room and can't see it, and we'll get to see the slides later, there's a nice, shiny picture of a nice, shiny thing with a faked up sticker on it. We have real stickers now, by the way. We're moving on. Okay, so what have we been doing here in Bunya Luca? Why is it that you've seen... There's certainly some of you have noticed that there's been a group of us in the back room of the upper hack lab at various times with these things spread out because of yelling and screaming and pulling of hair and gnashing of teeth going on. What has it we've been trying to accomplish while we're here? Well, I arrived at DebCamp with this as my set of objectives. First of all, I can't tell you how marvelous it is for me to have had some focused time to sit down and work collaboratively with other people who've been here on several parallel things that were all sort of necessary to make progress on before we can start delivering, you know, initial development snapshots of what might eventually be a reference software implementation. I really wanted to, you know, finish the process of assembling some initial development images and arrive with the objective of identifying and integrating at least one application that we could build on top of that development image so that people could actually start playing around and trying to use things. What we've actually accomplished this week, well, first of all, particularly as folks who are watching this from afar have been aware, there have been many talks and meetings at DebCamp that were directly relevant to things that are of great interest to people in the freedom box world. And so before I even talk about the things that we've done, there's been an immense amount of good work happening here at DebCamp and being reported on here at DebCamp independent of what I and the other folks around me have been doing. The second thing is, as I mentioned, we did get Marvell to release to us the source code of the micro-AP user space tools. And one of the first things I did last week in DebCamp when I got here was to package those and upload them and they've been accepted and are now in Debian unstable. So they're relatively small packages, UAP, U-T-L, and UAP event, but for those of us trying to work with these devices, that's important stuff to have there in order to be able to interact with that wireless device. We spent a bunch of time working on tools for building reference implementations. This is the classic problem. When it comes to tools for building images for things like ARM devices, there are lots of choices, none of which are exactly right for the task at hand. Jonas and I in particular have had lengthy conversations about exactly which pieces are the right pieces to use. I have a tool set that I've affectionately named as a filmmaker that I'm using to build freedom box images. It's sitting in a Git repository at my home server, the same place on my packages live. I suspect that once we get through one or two more arguments about exactly what the right way to do things are, that I'll push that repo over to one of the Alioth collab main kind of repositories so that other folks can have more easy access to that going forward, but it just hasn't happened yet. We've done a lot of work with Uboot for the Dream Plug. In fact, when I say we, it's the royal we. We've had a lot of help from a guy named Jason who's not even here, but who has in the past expressed quite a bit of interest in getting the Uboot content required to make a Dream Plug work integrated and merged into Uboot upstream. He had kind of abandoned that activity due to becoming very frustrated at not having all the information he needed. When Clint and I had a conversation about this last week and realized that, oh, we should tell him that we have the source code from global scale now, he got all excited, has done quite a bit of work while we were here, and there is now a patch set that's in the process of being reviewed and heading towards Uboot upstream. I would be really thrilled if we're able to run a Uboot executable out of the Flash on the Dream Plug that's built from the Uboot source in Debian. I don't think we're that far away from it. We've also done quite a bit of work towards being able to build usable packaged kernels. This is a place where, again, Hector has been very involved in helping with this. Various other people have jumped in at different times. As I say, I'm pleasantly surprised that once we started looking at some recent kernel sources, more recent than what's currently shipping in standard Debian kernel packages, a lot of the things we need have actually been merged in. There's still a diff. There's still things that need work, the extent to which we can go back and apply more pressure to Marvell to help them be adequately motivated to finish getting those things done versus the extent to which we will have to engage in those activities, I don't know, but that's something we've worked on a lot. We've had lots of discussion about and work towards selecting some applications for initial images. I'm not going to pretend that I'm prepared to announce today what the initial functionality of the first image will be, but one of the things that looks very promising is a vertical slice of functionality based around an XMPP server. We've also had quite a bit of discussion about different file serving techniques, and I feel like we're getting close to the point of having the right pieces to bring together an image that's not only suitable for compiling and testing things, but actually maybe for starting to use some things as well. So how do we go forward from here? Well, first of all, once I'm done with this talk and Bob, I'm running tomorrow morning, I hope to spend the rest of the time I have available documenting and working on communicating the things that we've accomplished here. We will very soon release some initial development, developer images for the Dream Plug, and thanks to work done by Lars and others, there are now some tools that make it really easy for us to take the sets of packages that we want to use in the Dream Plug images and also emit an X86 image that can be booted in a virtualized environment. This should make it easier for some of the people who want to help work on and collaborate in putting together user land software for the Dream Plug to be able to work with us. It's interesting to me, though, there's sort of a dichotomy in my mind between the things that have to happen to make any software work and be distributable and supportable on a device like this and lots and lots of things that can happen without having a special Freedom Box build at all. After all, everyone running Debian can install Debian packages, try out different pieces of software, help packaging the software that's not already packaged and figure out config files. You don't need some fancy target in order to do that. I also think it's very important very quickly for us to bring together the core elements of an identity management layer based on open PGP keys. We are currently on a path to using a lot of the monkey sphere bits and pieces and exactly how that interplays with these ideas we have about ways of maybe making initial... initial associations between devices where there's a lot of work to be done here, but it's pretty clear to me that that's the way we're heading. We know better technology that we have been able to come up with in our discussions than using open PGP keys as the basis of the identity system for what we're building. And then as I said, as we select and integrate specific applications that deliver the functionality that's implied by our vision, we will be issuing periodic releases until we achieve something that we look at each other and go, yep, okay, that's a 1.0. What will the exact timing of this be? I wouldn't venture to guess. It really depends on how many of you and how many of you out there in the big wide world who are listening or who come across this later are willing to dive in and help us do things to get there. So how do you help? Well, first of all, please be conscious about privacy and your other freedoms in everything that you do, particularly in W. Particularly if you are building and packaging software, just a moment, same time you're running all those Lintian checks and doing the other stuff. Give a little bit of thought to what are the implications of decisions you're making about standard configurations for packages and all of these sorts of things. Anything you can do to help make Debian more privacy enabling and privacy enhancing will end up helping all of the work that we're trying to do in the long run. Secondly, as I mentioned, please experiment with software. There's a wiki page. A lot of the stuff related to FreedomBox is hosted on wiki.wm.org and there's a page there called Leaving the Cloud. Please review the software that's talked about there try it out, work with it help us improve that page and come up with specific recommendations about the software and its associated configurations that we should bring together to make this all work. Join one of the working groups as they're formed and do whatever it is that you feel willing and able to help us with in that regard. And I would be remiss if I didn't mention that financial contributions to the foundation would always be welcome. There are a couple of ways to do that which you can find on the website. With that, I'm going to stop. I'll point you to these two websites. One is the FreedomBox content on wiki.wm.org and the other is the main FreedomBoxFoundation.org website. I'm told by our talk master here that there's about a minute left before I'm supposed to stop. So if someone has a burning quick question, great. Yeah. Zach. I think one of the big challenges is actually the user interface because it should be used not only by geeks but by how many people we can imagine. So do you have some advancement on the front? Would they come later? There have been many discussions with Evan and James and Ian and others at the foundation about who the right people are to talk to, to try and find someone who would take a leading role in working on the user interface stuff. We've had lots of conversations with lots of people and so far we have not yet found someone who has the right skills to do the work that's needed and to lead that activity who can afford to do it without being paid. And that's a tough challenge right now. We either need to find a source of a bunch of funding to be able to hire some of the right kinds of people or we need to find people who are interested, willing and able to do that kind of work who we haven't already found out about. Okay. Our time is up. Thank you very much for your time and attention.