 Hi, I'm going to talk a bit about foresight, a relatively recent Linux distribution and what the issues I think we are heading value to the overall Linux distributions landscape. From the user's perspective, the added value of a Linux distribution is to make an easy way for the end users to use the applications they care. The distribution layer by itself has no value. The value of the distribution layer is the value of the applications that are made available by hit. We call ourselves or at least we like to think we are a next generation Linux distribution. What makes us unique is that we broke with past in sense that we are not using a traditional package manager. We are not based either in APT or RPM or something based in some philosophies. We are using Konari. Konari is some sort of revolutionary. I'm not going to talk about it. It has lots of cool features. I'm going to talk a bit about what it hallows, not how it works. If you really want to know how it works after lunch, Michael Johnson will give a talk about it. It's much better than me. But Konari has some nice features and one of the nice features Konari has hallows us to claim we are the only binary based rolling distro. It's easy to make a rolling distro if you are using source based package management, gentle, hard clean looks, the BSTs, it's trivial. When we try to do that in a binary distribution, we quickly, quickly hit major roadblocks. Then foresight is about taste. We don't try to teach the user what is wrong, what is bad. We provide same defaults and same choices, but we always left final choice to the user. We don't block access to the user for certain kind of applications if we legally can provide them. We give away for the user to show, to choose. It's up to them and it's up to us to assure that all applications run okay, run well side by side and don't have a lab. One of the major impacts traditional package management as to end users is that it creates a big gap between application authors and users. Basically when someone do a major release of some application, it doesn't get quickly enough to end user because sometimes it was released in the middle of the release cycle of some big distro so it can't be put there. Then we have situations when application authors are developing the next version but are making point releases backward compatible with holder releases. There are two major ways of time. The other main issue we have is that basically we have major and minor distribution releases not for philosophical reasons but for practical implementations. It is very hard in a traditional distribution layered with traditional package managers to change something really deep in stack because it will affect so many things that simplistically it's not realistic to try to change. And when one really needs to change what happens and one needs to sheet, one needs to sheet gillipsy symbols, one needs to sheet all kinds of stuff for the distribution things that is using an older version when in fact is using bits of a newer one. That's also one of the reasons why in some distributions there are so many people working in new stuff as they have people back porting stuff to older versions because package management doesn't allow the process to be streamlined. So, our goal is to bring applications in a stable fashion faster for users for them to provide faster feedback. Also, there is a philosophical issue here. I don't think that the role in the long term of a distribution is to sit between a user and an application. The role of a distribution is to sit behind the application. For any user what really matters is the application. So, the distribution should be as much invisible as possible. Right now, we are shipping for site 1 which was a traditional Gnome desktop, was 32 bits, only works is stable and we have a nice user base. What will come next is much more ambitious. We will ship not only a Gnome edition, we will ship a KDA edition and we will ship XFCA edition. Also, we will ship in 32 and 64 bits and we are trying to achieve full pitch per feature parity. Also, we have some simple but worth equals. We want to make sure that any Gnome application will run well in KDA and vice versa. Also, we are not following the roads of other distributions, whether they have slightly similar cores but then they have fully divergent interfaces with Ubuntu, Qbuntu, Gnome, Ubuntu or whatever. Basically, if you are in Gnome and you want to swap to KDA, it's a simple matter of a single command and you go from Gnome to KDA vice versa. You don't like, well, Konari is powerful. You simply do Konari rollback that goes back to the software you had previously installed. It will work. Also, what we would like foresight to become was some sort of Switzerland of distribution. Not in the sense that we want to dominate the world, but in the sense that we provide common ground for application authors to come back faster for hand users. We already used as the back end of the Gnome developers kit. It was not because of love of Konari or for love of us. It was because our framework was only at realistically load. Daily go to the Gnome SVN server, fetch the sources, build them and consistently getting the updates daily for the people in the documentation team for actually patched quad and so on and getting what got fixed and what didn't get fixed. We opened Neofeature to extend this service. We provide community also to KDA community and to the XR community. Basically, having an appliance like reference design and people can sit on top of it and see what works and not works. Then if people want to brand it their way, they can way. If they want to make it the underlying environment of some kind of specific application, they can. I don't know 10 years from now if foresight will still be available. I also don't know if Konari will be available. One thing I'm sure, this model that puts the application in the center of landscape, this model that says it's not distribution that says which applications can run. This is the fact that I provide an application and the underlying package manager. In order for you to run this application, you need this kind of packages and ultimately technology allows you to build an image with just what is enough to run that application, that desktop application. You can think in terms of single applications or you can think in terms of families of application for specific uses. The other interesting point about Konari and about foresight is that independently about how much we like ourselves realize that we are not center of the world. The biggest problem we have with traditional package management philosophies is that they are centralized. Of course, any distribution can make to work if there is a centralized pyramidal development work in where there is one person who defines everything. If you do it in a perfectly self-contained sandbox, of course things have a good chance of work. But this is about distributed development. This is about distributed package management. We don't want to have whole repositories. We simply have guidelines. We simply have framework. If someone wants to package anything and follows our rules, it doesn't even need to talk with us. Konari, the underlying package management will do everything. What needs to be updated from us will be updated from us and what needs to be updated from them will need to be updated from them. In that sense, we are fully distributed. I'm not going to talk too much about Konari, but I just will say that Konari is not a simple package manager. It's also bits of soft control management. Think mercurial. Now apply this to distribution. If I suppose that some of you have experience developing software and packaging, you're not paying. I won't waste most of your time. I will just say that if you have 10, 15 minutes available, go to our website, grab one of the best of foresight tool. It takes five minutes to install and we use HANA content, really, five minutes in bare metal to install and give it a test drive. If you like it, stay with it. If you don't like it, well, try again soon. But I think that what we will find some challenging stuff we are doing. I think I have three minutes left if someone has some question that would like to do. Anyone wants to do any question? Yeah, no. Basically, foresight is trojan horse. We need to ship something. So, of course, we ship applications. The way we ship to the applications and technology use, we call it platform. It's called foresight, which is built on top of a very small and scalable Linux, RPL Linux from our path. It's basically what's made from appliances. So, in some senses, foresight is a desktop appliance. It can be run inside a virtual machine. It can be run natively. We can run it on Sunrise, whatever you want. It will work. But foresight doesn't have as an ultimate tool to preach about some specific philosophy. We try to put the applications you expect to be there in the same way, in a standard way. We try to follow as much as we can upstream. We try to be best of breed. If opens use as a good Hexhork stack, we go and pick them. If someone from Red Hat is doing something we think is worthwhile, we go and pick them. The big difference is that, I just found that last night, there is no one at Red Hat that is actually running raw-wise at this desktop. But you can guess most, if not all, of the interesting features that are in raw-wise. Today, today in foresight, and they assure you foresight is stable. So, sometimes we get people from Red Hat asking us to put it there because we get more feedback. Because, in fact, we have users. So, basically, from an application point of view, we reduce time to market. If you like to be on bleeding edge, you have two choices. Or you play Russian roulette and go for ultra-instable distribution or compile yourself, or you go for foresight. That's no middle turn. So, that's the biggest difference. Otherwise, we try to be graphically, we are calm, we are not too fancy. What needs to be there is that we are discreet. We don't like to make noise to confuse the user. Our target is the user who doesn't care too much about Linux, since it's not religious. Someone really wants something that works, doesn't care too much about what it is. So, we like the appliance model. Okay, that's all.