 Okay, we're good to go. So this is Phillip Papps, who's a FreeBSD developer, who's going to be talking about the K-FreeBSD port in Debian from the FreeBSD point of view. Yeah. So in case you were wondering, I didn't submit to the wrong conference. I'm aware that this is a Debian conference, but you may not be aware that Debian is actually a FreeBSD distribution. So this talk is the talk we actually usually give to large companies who build products based on FreeBSD and who want to be more involved in the FreeBSD community. And I felt that given that Debian is also a large company or organization, if you prefer, who are including FreeBSD in their products or their distribution, it would be a good idea to give you guys this talk and let you know how the FreeBSD project works. And also there's a number of reasons I would like to give this talk. So K-FreeBSD allegedly is part of the next Debian release. You guys take a different approach to the whole distributing FreeBSD than everyone else does. You use your own user space for reasons which are no doubt very interesting. And I think K-FreeBSD does actually have great potential for reasons I'll expand on later on, but there is one thing that I have noticed, this little slide of statistics. We have developer summits as a FreeBSD project at our conferences every now and again. And the number of Debian developers at this last summit and the one before and every Dev Summit, as a matter of fact, has always been a very round number. And if you compare this to the number of Juniper employees who show up at Dev Summit, which is not a very round number, just a very large number, it's a bit distressing. Especially since, comparatively speaking, Juniper's use of FreeBSD is much simpler than what Debian is doing. Also, the number of commits to the FreeBSD head tree, oh, question. Okay. They've just been hiding then, maybe. The comment was that there have been some FreeBSD, some Debian developers at Dev Summit. For the second point, number of commit to add, I, okay, there have been some patch submitted by Debian that have been merged into add. Not a lot, I agree, but there have been some of them. Well, I just, because Subversion is not exactly the most searchable revision control system, I just did 2010 a quick grip for obtained from Debian and that returns a very round number. So I'm sure in the past there must have been some because, well, it's working. So you can't possibly have it working without some kernel support. Microphone, microphone. I also can't tell you that sometimes there is fixes in software that benefit FreeBSD and that go directly to upstream, for example, in QAE. Yeah, no doubt there are some Debian code in there, but it's just not very visible. But the next statistic is definitely a real zero. I don't think there are any Debian developers with FreeBSD commit bits. And if you're going to be a distribution or a credible distribution, I think someone should probably get involved with FreeBSD enough. I'll get into that later in this talk. And just, well, I don't think there are any FreeBSD developers who are also Debian developers, but I don't think that's a relevant statistic. So this talk is how the FreeBSD project works. So I'll talk a bit about what FreeBSD is, what you get with it, and how we do third-party applications. And then I'll contrast this with what Debian FreeBSD is doing and how I think it's better or not so better in different places. And then I'll talk a bit about how the FreeBSD project works, which you can then contrast with how Debian works as an organization, as a bunch of people working together on the same operating system. And this should maybe inspire one or more of you who's also working on FreeBSD to maybe join the FreeBSD project and help out from that end. So FreeBSD is an open-source BSD UNIX-derived operating system. We are not just a kernel, unlike Linux. We are a complete operating system. We have our user space, libraries, all sorts of tools. Everything just fits together. You can build it all with one command. FreeBSD is very popular in the ISP network space. There's a number of really large ISPs who have thousands or tens of thousands of machines running FreeBSD, and they are very happy with this. Some examples are listed there. Yahoo is obviously the big one. New York Internet, they're just around the corner. Well, corner-ish somewhere. More recently, FreeBSD has also been gaining some visibility in the embedded application space, embedded in the sense that the operating system comes with a device, not necessarily that the device will fit in your pocket. The devices these people make tend to be on the order of fitting in a small-sized apartment building rather than in a regular-sized pocket. And also FreeBSD has been used by a couple of companies to build their operating system. These people usually take parts of FreeBSD. In the case of Juniper, they take the whole thing, but they diverge in the network stack. Mac OS X, they've got their Mach kernel, and they stick the FreeBSD user space around it, which is, I think, exactly the opposite of what WNK FreeBSD is doing. You're taking the kernel and sticking your user space around it. So that's interesting. FreeBSD is arguably one of the most successful open-source projects. Obviously, it depends on how you want to define success in the open-source world. I think that having tens of thousands of deployed machines is a pretty good measure of success. WNK is also a highly successful open-source project, but you can't use the internet without using FreeBSD. The focus of the FreeBSD project is storage, networking, and security, not to the exclusion of any one of those. There's a phone ringing, and it's not mine. So the FreeBSD kernel, which you are borrowing, is a multi-processing, multi-threaded kernel, which means it's finally grained. It will run happily on as many CPUs as you care to throw at it, within reason, but we are getting better like that. We support many popular architectures. I think Debian is only currently interested in i386 and AMD64. I don't know if anyone's done any work on any of the other architectures. FreeBSD is particularly gaining traction on MIPS. There's also quite a lot of work going on ARM, but MIPS is very big these days because the big MIPSs are very popular in the embedded space. Like Linux and every other operating system in the world, we have UNIX and POSIX interfaces. Obviously, we have BSD interfaces because BSD is what we are. Our network stack is the reference network stack for at least IPv4 and probably IPv6 as well. We have other obscure things in our network stack, too, like Apple Talk. I don't know if anyone still uses that, but we have it. More recently, the FreeBSD network stack has been the reference implementation of SETP, which is probably not something people are using at home. But if you're a large telco, you're probably using SETP somewhere. And our 802.11 wireless network stack is also used by people like Apple and Solaris are using it. So it's a very portable network stack. Our kernel is a unified kernel. There's no bits and pieces which can go wrong. It's all maintained in the same tree. You can build it all with one command. And we have extensive kernel documentation. Linux is getting better like that, but we do have very extensive kernel documentation. As I said, FreeBSD is not just a kernel. We also have a user space, which is completely integrated, as in completely the opposite of what the GNU thing is doing, where there are hundreds of teams working on each application separately. The FreeBSD project maintains all of these things in an integrated sort of way. So all the tools you'd expect on a FreeBSD system are there by default. If you type make world, you will get them all. And we have build time options which can disable many tools for the smaller embedded spaces. And we think it's interesting that the kernel and user space are maintained by the same people so that if something changes in the kernel, user space can follow. We have a strong policy of, we call it Bola, the path of least astonishment. If something changes, or if there's two ways to make a change, we go for the one that will astonish the least number of users. If you can break a user space kernel space interface, or you can just pad a structure at the end, we go for the gentle thing. Again, our user space is also extensively documented. This is where you guys are diverging. You, for whatever reason, are not choosing to use our user space, so you don't get this. But our user space is there for you to use if you wanted. I'll get back to that later on. We are modularizing lots of parts of FreeBSD server. There are some tools which you want to provide the user an option. Sorry, yeah, microphone, microphone. Yeah, but if you want to give the user an option, you know, GNUGREP or BSDGREP, you can do that. I think BSDTAR is already in Debian, and I use it to great satisfaction. So that brings me to a question, I guess. But it's really of the audience. Is there someone here who is really active in Debian GNUGREP FreeBSD? Cool. Cool, cool. There are. Didn't stall? No, that's cool. I've, to be honest, I've not tried it myself. I run a company with Wadri who's in the back of the room, and the last time he tried to install Debian K FreeBSD in a jail, he panicked the machine, and since then he has not had root access, he has not had root access on that machine since. So, yeah. So, mixed success. Well, it's in the official Debian distribution, so I assume it's a credible port, and I'll get into that later. But I think Debian K FreeBSD has a number of really interesting applications, and I would like it to succeed as much as, well, presumably you guys do. And that brings me actually neatly to this set of slides here on features we've got in user space in the kernel, and that's jails in virtualization. The last couple of years, the FreeBSD project has done an immense amount of work on virtualizing FreeBSD in a way that other operating systems don't necessarily do it. There's a couple of popular ways of doing virtualization. Either you take the whole machine and you pretend to be a CPU and you under the carpet do things to make this fast. And then the other way is the way which Solaris has done with containers and little boxes and you try to keep your applications in there. FreeBSD has done a little, yeah, a little different sort of approach. We've got jails which are a shrewd with network connectivity, and as I'll talk about later, and these days an entire network stack too underneath the jail. So you can give random users root access in a jail. They're not on the base machine because then they will panic your machine if they try to install Debian. But this... I mean, I know. But this makes it really easy for web hosting companies, for instance, who want to give random users for a certain amount of money a month or a year or whatever. You know, this is your little virtual machine. You can be a root here. You can install whatever secure or insecure applications you like. And no other customers are going to be affected by this. And this is actually one of the places where jails are seeing a lot of use. And this is somewhere where Debian. FreeBSD could come in really handily because Debian is a great desktop operating system to continue amusement about it. I do run Debian on my laptop. And I think it's a great desktop operating system because package management... We have package management of FreeBSD as well, but it's not quite so easy to deal with individual binary packages or to deal with packages on a machine that changes every now and again. Or if you want to follow certain packages, it's difficult. It's not impossible. It's just difficult to do with the FreeBSD package managing system. And APT and the package or the combination of the two actually makes that really nice on Debian. So if you can stick a Debian K FreeBSD in a jail on FreeBSD and then just give a random user, here's your root password and just deal with it. And you can use the package managing tools you're used to on your desktop, provided you use Debian on your laptop. We assume that everyone does. You can use the same tools on your server and it'll be a familiar environment. The only difference is that you have the power of FreeBSD underneath as in, well, not that the Linux kernel is bad in any way, but our virtual network stacks are something that makes hosting companies really happy. We started working on this, well, the first prototype was a long time ago, but we started really working on this in the FreeBSD 8 and 9 release cycles. 9 is still working, but the V-image work allows you to plug a whole network stack underneath the jail as in layer 2 and layer 3, everything above that. You can assign multiple IP addresses to jails. You can run a firewall per jail, if you like. So, pretty much, there's no real difference between running on a naked machine and running inside a host from the user perspective or even from a root's perspective. The only way you'll be able to see that you're in a jail rather than in a real machine is you'll have a couple of syskitels that look different and you'll have one disk instead of maybe 100 disks underneath. This is a key feature, and if we could get WNK FreeBSD running well in jails, does it actually work now, installing in jails? You guys should know. Sorry? Microphone, microphone. So, yes, we are able to run jails on the GNUK FreeBSD, but we are not able to run a GNUK FreeBSD, WNK FreeBSD jail inside a plain FreeBSD. There are still some problems to solve there with the kernel. Okay, but... That's a goal. But all those problems are known, or the problems are known and being worked on, so it's not... It's not, I would say, they are known, but it's not the top priority right now. Okay, because from the FreeBSD perspective, that would be something to work on, and if FreeBSD can help you out there, then I'm sure someone will be happy to, maybe not necessarily me, but someone can probably volunteer. But, yeah, so the combination of a virtual environment with a user space, which is familiar to many people, because it's what they use on their home machine, then that would be a great market. I could name a couple of hosting companies who are very interested in that sort of environment, because I do have to admit that package management in FreeBSD is not for the faint of hearts. FreeBSD, in addition to our wonderful jails and network stacks, we have documentation for everything, which may not be relevant for KFreeBSD, because your user space is so vastly different from ours, but I just wanted to point out we have man pages, we have release notes, and everything else, and books, people like reading books. Our third-party applications, I'll talk about briefly, because it's... Debbie and KFreeBSD doesn't use them. We have something called the Ports Collection. It's a source-based package management framework, rather than the binary sort of thing Debbie does. This means that you basically have to compile your packages. We do have binary packages, but if you want to diverge in any way from what's provided, you just need to compile them, and you find that pretty much everyone compiles, either you have one central machine building packages for 1,000 others, or you just have the machines run some scripts to update your packages that way. We've got 18,000 of those. I don't know how many packages are in Debbie in these days, but it's probably in order of magnitude more. We don't tag our packages to releases, which I think is different from what Debbie does. We have one Ports Tree, which is always heads, and it always builds usable packages or allegedly usable packages, depending on if the package itself is useful in the first place, on the current supported release branches. Our FreeBSD Ports Collection does make it really easy to maintain local packages. That's also possible with Debbie, but it's not easy, I think, maybe. We have a Linux binary compatibility layer. I don't know if KFreeBSD wants to use this, but it's not an emulator. We do system call wrapping, so system calls have numbers on Unix, and we just look system call 4 on FreeBSD is reads on Linux. The implementation is slightly different, so we just map them to stubs, and that's blazingly fast. It actually makes most Linux binaries run reasonably well, provided that they don't have any sort of funny dependencies. It's a translation layer, so obviously it runs behind Linux, and it's often not the favorite thing for people to work on, so it was recently updated to work with Linux 2.6, which has been out for a little while. Most Unix and Linux applications will just work on FreeBSD either through the ports 3 or just sticking binaries on there, but you're obviously replacing that with your own. More interestingly is what the FreeBSD project is and why I invite you to join it. The FreeBSD project is much like the Debian project, an online development community. Unlike the Debian project, we have central source repositories with revision controls and not just a central package repository or package database or whatever it is you call it. We have rather fewer developers than Debian, I think about a third. Last time we counted, we had 364 CVS committers, where we currently call them subversion committers in the source case and CVS committers in ports, and we have thousands of contributors. I have a little graph later on. We have lots of mailing lists from much the same thing as Debian. Our license is different from Debian, while Debian does the free software with the capital F thing, which I won't talk much about. We do the Berkeley license thing, which basically means we write the software, we enjoy writing the software. If you enjoy using the software, you should do so in whichever way gives you the most pleasure. If that means selling it or using it in binaries, that's fine. We don't care. As long as you don't say you wrote it, we're happy. So by all means, go wild and use it. We also have a foundation. I think Debian has a similar sort of construction. Ours is a non-profit organization, and it takes money for FreeBSD and gives it to FreeBSD. It also tries to provide some legal shelter for tricky things like we do contract development for some of our corporate users. The organization also sponsors travel grants to our conferences and buys hardware, lots and lots of hardware, and negotiates agreements, but that's not very interesting. FreeBSD project produces a number of things. We produce the kernel, we produce our user space. We produce a security officer. He's been produced a couple of years ago, presumably by his parents. Similarly with the release engineering team. We also produce the course collection and binary packages. We make releases every now and again. It would be nice if we could somehow synchronize releases in some way, but down that road may lie madness. We produce books, handbooks, web pages, and marketing, and we do technical support on mailing lists. We also do flame wars if Hannah is still here. And we also organize conferences. Of course we don't produce without actually consuming. We consume the same thing as Debian developers. Beer, soda, vice of choice here. We love hardware. I think the Debian project, I saw something on the Debian channel about machine naming. I was complaining about, I can't remember these machine names. We have the same problem. We love hardware, especially if it comes in big racks with hands to press the big red button when they fail. We consume bandwidth in vast and old quantities. It's impressive how much bandwidth we use. We like to travel to conferences. We like to eat every now and again. So salaries come in handy. Or contracts for those of us who are contractors. And like everyone else, we thrive on thanks and good press. Oh, and more bandwidth and more beer. We have processes which surround our people, much like the Debian project, but our processes are maybe a bit different from the Debian process. We have a concept called a committer, which is someone who can type CVSCI or SVNCI and it will work rather than complain. In Debian you have Debian developers who upload, I'm told. I'm not entirely sure about Debian proceedings. We have a core team who sits at the top of a tree and does many unspeakable things. I'll talk about them a bit later. We have two classes of committers, but they're not class A and class B, or in any way subservient to each other. We have the ports committers and the maintainers who live in the ports tree, and then we have the source team who works on the kernel and user space. We have various groups and projects, all sorts of other things, all of them so I won't. So how does this all work? It works differently from Debian. I mentioned that committers are people with subversion or CVS rights. We select our committers a bit. I think Debian also has a pretty tough selection process, but the previous process is not casting concrete. We basically look for technical expertise on the area of code the committer is working on or the proposed committer is going to be working on. There should be a history of contribution to the FreeBSD project as in we don't give commit bits to people who say, yeah, I write some C and I would like FreeBSD commit bits. We don't do that. We like our committers to work well with the community to avoid flame wars. Generally, proposed committers should make these characteristics obvious and then we punish them with commit bits. Generally, committers are invited rather than proposing themselves. A key concept in the FreeBSD project is the concept of a mentor. Every proposed committer is proposed to the core team or the board manager team by someone who volunteers to mentor them. Basically, that means for the first couple of months or weeks or whatever, of the proposed new developer working on the FreeBSD project, the mentor will read through their patches and generally collect pointy hats on their behalf if they do something wrong. Our committers, we have rather fewer of them than Debian. Their last time I counted in 34 countries on six continents, which I think is all of them except for Antarctica. Our oldest documented committer was born in 1948, which is a very long time ago. Our youngest documented committer was born in 1989, which makes me feel old. And the interesting thing is that our mean age is rather old compared to some open source projects. FreeBSD developers tend to be professional programmers. We have some hobbyists, lots of consultants, a couple of university professors in the most diverse fields you can imagine and some students as well. We do the Google Summer of Code thing as well, and we've got a number of really interesting committers from that. This is a life little map. It's out of date. The usual clusters of where people are. A heat chart, which is similar. Age distribution is fun to look at. Yeah, I'm somewhere in the big bunch. Ha-ha. Our committers, I mentioned, we have a number of types. We've got ports and source trees. We've also got documentation. It's about equal, well, not quite equal thirds. It's unequal thirds distributed, but many source committers also have ports commit bit. Many ports committers also have source commit bit. And just about everyone commits to doc every now and again when something gets changed. Yeah, this is just a more blown out, I don't have time. So the FreeBSD project is divided up in a number of groups. We can roughly divide them up into developer groups and administrative groups. Source developers core team, core team secretaries, lots and lots of them. Probably the same situation as in the Debian project. Everyone is part of a team or many teams and everyone is generally overworked. We have many more teams. So in addition to this list, we still have this list. There's nothing very exciting on here. I think we have, no, nothing exciting on there. We have a core team, which is different from Debian. Debian has a fearless leader at the top who is elected every now and again via a process which sparks lots of mailing list discussions. The FreeBSD core team is a rather quieter body. It used to be key developers who got shouted at a lot and shouted at other people a lot, but it became a democratically elected body in 2000 and we've recently had our latest core team elections actually in June and there were no flame wars. Well, not many flame wars. The core team consists of nine people because one person couldn't possibly handle the flood of email. There's a core team secretary. That's me. I get to read the email, but I don't get to vote and I don't have to take responsibility for anything other than writing monthly reports. The core team has a couple of administrative responsibilities. We approve of new commit bits and we bless hats. We say, you know, you can have roots on this machine. The core team deals with that. The core team also has a strategic role. We guide roughly where the FreeBSD project should be going and we brought people into action like that. Sometimes the FreeBSD core team secretary gets sent to a conference about the Debian projects to talk about, you know, there's this Debian K FreeBSD thing and maybe you should brought them into action. So that's what I'm doing now. And the main thing the core team does is basically resolving conflicts. If you put 50 cats into a room, you're going to have 50 cats fighting in a room. Most FreeBSD developers are fiercely independent people who have to cooperate on codes and have to display common sense and they have vastly different opinions on each of those subjects. So sometimes, obviously, this explodes and you get a flame war. The FreeBSD core team tries to mediate these flame wars in a gentle sort of quiet way to avoid flame wars, actually. As I said, yeah, we have many, many ports committers, but we have even more maintainers. I think in Debian this is slightly different, but I don't know how exactly it works. We have 160 ports committers and maintainers just maintain the ports. It's a line in the make file and a couple of committers pick up on them and CVS commit them. So that's how we work. He worked differently. An org chart is difficult to draw with this sort of strange spidery organization. We've got the core team and the foundation at the top or the bottom, depending how you look at these things. We bless a bunch of teams who do various things at the top. The security officer blesses the security team. Release engineering deals with admins and at the baseline of this chart, we've got the people doing the actual work, which are the committers and the ports committers, source committers, lock committers. So I think this looks roughly like what Debian looks like too. Just the labels are different. We have lots of mailing lists, each with their own special variety of flame war. I'd actually be interested to see a comparative analysis with the previous emailing lists and the Debian mailing lists just for fun. Most of our mailing lists are public. Some of them are private security. Officer is obviously private and if you type this command, 3BSD kernel will blow up remotely. We would like to announce this in a somewhat responsible way to the world. We have machines everywhere. I think I mentioned machines. We like machines, especially if they come with hands. We've got two clusters sitting on the left side of the US on top of an inconvenient fault. So not mentioned on this picture is that recently we've got a data center being worked out on this side of the US where there is no inconvenient fault. We've also got a cluster in Denmark and we've got some stuff in the Netherlands too, underwater. So we've got machines everywhere. I think this is similar to the Debian project. A key thing in the 3BSD development model, moving right on, I think there was an outline slide missing there somewhere. That happens. 3BSD does the branched development model. We have a current branch, which is the head of the development tree, and that's always the same. You would call this SID or unstable or unhappy or maybe even experimental. I don't know what you'd call it. Of that, we branch a stable or supposedly stable branch at regular points these days. We try to do them every 18 to 24 months. We try to say let's branch heads into something stable and then we further stabilize these branches into something which is really stable and then we call them releases and we release them to the unsuspecting public. I don't know where K3BSD would want to be. Last I've seen is that your kernel is based on 3BSD 7.2, which is on 8.1 now, and whatever I was reading is out of date. So you're obviously tracking release branches rather than stable or definitely not tracking head, which is probably the best idea. So, yeah, I don't know how often do you want to update 3BSD if you want to stick with... Yeah, it mainly depends also on the way Debian evolves. We have to stick with the stable release from Debian, so it's chosen each time. There is no real rule. So, for instance, say, next Debian would be released with 8.1, then you would be on 8.1 for that whole release of Debian? For the stable release of Debian and probably you are going to switch to a newer kernel for squeeze plus one. And do you maintain the lower version number? Do you want 8.1 to stay the same for squeeze or will you go for 8.2 at some point or 8.3 if that ever happens? We are probably going to back port a few things, but stick to 8.1. Because that's one incompatibility with Debian and 3BSD is that Debian has this strict policy of whatever's in stable or release or whatever you call it stays the same, and if you're going to stick with 8.1, you're going to lose out on a lot of fun things in 8.2. Allegedly, nothing really major happens on stable branches, but things do happen. More questions? Since we're talking about that, how long are the release cycles in terms of end-of-life? So, if Debian has a release cycle of X many years, what's the release cycle of those 3BSD kernels, and are we going to be running into a problem where we're going to be stuck on a kernel that's no longer supported in 3BSD? That's exactly my worry. We have two sets of end-of-life cycles. We've got the standard sets, which I could look up, but I don't remember which is reasonably short, and then we've got the long-term support or longer-supported branches, and I think they're two years or something after the last release of the stable branch, which may be a bit short for a Debian release cycle, but I know that saying that I will probably have a herd of mad Debian developers shouting at me. Really, if you're going with 8.1 for the lifetime of a Debian release that may be well, I'm not going to say unwise, but that may be challenging if you are going to say take 8 for the release and stick with 8 because these stable branches are not supposed to break in any way. We don't break the kernel interface, we don't break the binary interface, we just add bug fixes and sometimes we merge features back. That's not that different than what we do in stable, in terms of bug fixes, but are these branches for the kernel and the user space? Yes, we have our whole operating system. How much does the kernel change over the course of one of those stable branches? That really depends. Sometimes, not very much, and sometimes a feature which has been gently simmering in head gets merged into a stable branch at some point between, say, 8.1 and 8.2. A driver which was in head for a good while but not deemed ready for 8.1 will suddenly appear somewhere between 8.1 and 8.2 and then will be part of the 8.2 release in terms of big architectural changes so if a subsystem has been cooking in heads and it didn't make it for 8.1 release, it's not going to make it for 8.1 or 8.2 either, except when it does. But, yeah. It usually doesn't happen. So if you take 8.1, you have the benefit of, you know, no surprises ever. The only thing that's ever going to be committed to 8.1 are security fixes and for the kernel, there are usually not very many security fixes, but I don't have statistics about, you know, kernel and user space security fixes with me. If you're going to stick with the 8.1 release sets, that may be much more flexible for people who need support for a longer term, both from FreeBSD and Debian. That's obviously something that's going to pop up once KFreeBSD really exists is you have two sets of people giving security advisories. You've got the Debian projects and the security advisories for things in user space and in application space and then the FreeBSD projects issues security advisories on the kernel, so presumably Debian will take the FreeBSD ones if and when they are relevant, but it's something we also need to think about or someone needs to think about. Yeah, this is more about our development model. It's not very interesting, especially given the amount of time I've got left and the fact that the video team allegedly likes to take breaks. Yeah, one thing I would like to also mention is we have Perforce as an additional version control system. Our main tree lives in CVS and in subversion, but we use Perforce which is an evil proprietary system but it also happens to work really, really well for branch development for things which are not quite ready to go into heads. If you've got things for Debian KFreeBSD where you want to fiddle with the kernel in very interesting ways, which would make your life interesting, I'm sure you can easily get a Perforce account if you choose to use it to make your work visible that way and to poke around and track FreeBSD development actively. So I'm sure people would love to help you out with that. A number of big FreeBSD projects were born in Perforce. I'm not saying Debian KFreeBSD is supposed to be a big FreeBSD project but if you want to make it a big project then there you go Wild. The multi-processing project started in Perforce our MIPS port started in Perforce we put our summer of code students in Perforce and they seem to be doing well there they thrive, sometimes they get commit bits and they move into subversion. This is just a pretty picture which I thought I'd include of how branch development works now there's a Git which is a credible sort of open source thing which is the same so maybe more people will be using Git. An important thing I would like to mention FreeBSD project also organizes conferences they are rather shorter than DEB two weeks is a very long time to hold a conference or one week and a week of DEB camp is a very long time FreeBSD conferences tend to be two days long it's usually a weekend, Saturday and Sunday and we have developer summits one or two days before the conference, Thursday and Friday or whenever the conference takes place usually about 100-ish people show up to the DEF summits there are venues for working on ongoing projects it's amazing how much work can get done as you've probably noticed the same where you stick people in the same room without sharp edges and some beer and somehow code materializes it would be great if some Debian developers would show up to our FreeBSD DEF summits so we can talk to them about things they're working on and work with them on making FreeBSD easier to distribute as part of Debian obviously where possible we do like our user space as well if we can make it easier for other people to wrap their user spaces around Debian then we obviously encourage this yeah so I'm going to wrap up on time actually so why should you care about this presentation at all I've given a talk this talk usually we give to companies distributing FreeBSD deal with it you are now a company distributing FreeBSD you borrow FreeBSD in a very complicated way in fact in a much more complicated way than any other consumers of FreeBSD the usual case is either an application or part of the FreeBSD kernel gets borrowed usually is the network stack and that goes off to live a life on its own and then it gets merged every now and again Debian is actually just taking our kernel as a whole and plugging it into a completely different operating system which is a new and novel thing for both of us I think and it's interesting because we like, well the BSD license says it all we use it everywhere so if this gives you pleasure then it gives us pleasure to give you the software it's a great potential for success as I mentioned hosting companies would really like jails with WNK FreeBSD so users have their familiar environment for installing packages and doing whatever it is they do in user space and I think that if this is going to work well we should probably work together that probably means that maybe some WN developer should show up to def summits you're more than welcome just look at the wiki and just sign up as a guest that gets someone to invite you that's not very difficult more and more bits of FreeBSD are being modularized TAR was the example I gave earlier some bits of the GNU user space are interesting and the BSD versions are less interesting so maybe you can give users a choice of using the BSD bits rather than the GNU bits where possible or whatever you like but the modularization effort should also make the K FreeBSD effort easier we're not saying that we're going to make the kernel a package that flame work comes up every now and again and it never ends well but if we can make the life of distributions easier we definitely want to do that and I think if we can talk together about this we can do a lot of fun things together and that about wraps it up that was a three hour talk which I've compressed in 45 minutes I will happily take any more questions questions hold down the button go ahead hi I was involved in FreeBSD before Debian a long time ago and I've been working on the installer rewrite that tried to happen a long time ago it was called Live H it's happening again I think that's marvelous and the best luck to those people one of the problems I stumbled upon back then which may explain why Debian is not packaging userland well userland is this world big chunk of stuff that's not easily isolated in separate packages and as far as I remember it doesn't register itself in a package registry when it's installed so I guess I have two questions that's the first question is is there is there an objective in the long term of merging the port's collection package registry with the userland package registry so that there's a single package system or find a solution to that problem in general and the second one is is Debian's compatibility layer or is or was based on Red Hat and is there a plan to use what Debian streams instead the first question is the easiest the answer is no our port's tree is a tree the formal definition is it's a tree of third party applications as in applications which the FreeBSD project does not produce there are some applications in the port's tree the third party application is the applications but there are compatibility things for older releases but the port's tree is really for third party applications and the source tree is what we make that's our operating system and we want the source tree to be a complete operating system and where you draw the line for completes and not completes is obviously subject to interpretation we still have send mail and binds in the source tree and the operating system stops at Lipsy we dance around that line a bit but there's definitely no plan or no effort that I'm aware of and if it's out there somewhere hidden if it's hidden it's definitely not going to work but if it's out there somewhere I don't think it can work there's no plan to package user space I was mostly referring to the duality between tools like FreeBSD update and like port install or whatever FreeBSD update is in the base system it's somewhere in Rezbin I think but port's update lives in the port's tree that's true and port update is a bit of a funny one but the main reason it lives in the port's tree I think is because it's written in Node-C there's a number of applications FreeBSD project has a history of writing very useful tools in Node-C CVSup was a popular one for a while it was written in Modula 3 for reasons which only John Paulstra knows and it was recently rewritten in C and CSub now lives in the base system the question is how long will CSub be relevant now that we've moved to subversion rather than sticking with CVS so the general split is that third parking applications live in the port's tree and source is our operating system and I forgot on your second question Linux Red Hat I think it doesn't really matter what you're using for Linux Compat because the compatibility layer is in the kernel so it doesn't care what the distribution is because we are compatible with the Linux kernel not with some distribution of it I think there are a number of distributions and I think I may have them on my laptop but I don't know I know we definitely have Red Hat and Fedora user spaces in the port's tree I think we also have a Debian or a HAD or have a Debian in the port's tree as well HAD, okay, but it says HAD and once the microphone to expand on this so it used to be the case that the default was actually Debian but that was only up to potato because after potato we switched away from having a base target and then installing our base system was required having the bootstrap which you didn't have in the port's tree so it was actually stopped supporting and it's not there One challenge of the Linux Compat layer is that obviously Linux applications don't just depend on system calls they like libraries too and while FreeBSD Lipsy is a complete C library implementation it does vary in the number of places from new Lipsy we have in the port's tree a number of reasonably complete Linux distributions which we unpack in user compats or somewhere similar and then we stick to Linux applications where people stick their Linux applications under the same tree and you shoot in there and it pretends to be a Linux system and the user is non-the wiser or you jail in there and the user is definitely non-the wiser but I think the reason Red Hat and Fedora were chosen is because we have un-packagers RPM or RPM to CPO or something like that which makes it easy to un-pack Red Hat packages and while Debian packages are obviously just our files there is a little more subtlety there to just un-pack them and if someone feels a great need to package Debian for FreeBSD I obviously encourage this effort well that can do that in a scopious free time Any more questions? I have a question Well it's more of a question for the audience So can anybody here comment on the state of the KFreeBSD distribution? Is it workable as it is? Can I install it on my laptop? Will it give me everything that I'm used to having? I'm not sure my answer would be very objective given I am working on the port but I would say that on the server point of view this works very well you can reuse the server on the desktop part of view there is still some work to do that's where we are lacking I think the main market for Debian KFreeBSD is probably going to be on the market as I mentioned a couple of times people with huge machines running FreeBSD already or people with hundreds of machines running FreeBSD with jails on top of that would love to be able to stick Debian with jails or have a Debian FreeBSD machine as well but it would obviously be nice if the desktop worked too so I could run it on my laptop and get rid of the perpetual scorn from both of them I certainly think it's useful to have it I mean we had this discussion during the herd distribution talk this morning I think it's very useful and healthy to have these alternatives I think it could make both of us better, right? Debian could be a more very crude way of describing Debian is duct tape and spits to make new useful so if you can make it even more useful by replacing the kernel underneath that's great for you guys and for us obviously it's great that our kernel works with more than one user space that's not that there's anything wrong with our user space but we understand the sensitivities of many people and so so I have another question anybody else have any more questions? just real quick the jail thing you're talking about that's like a built in virtualization thing in the FreeBSD kernel yes it's basically it's root on steroids is how it started so you can just do change routes but in addition to just having your file system routed under a different directory you also have a network stack plugged into that and up to FreeBSD 8 the network stack is basically an IP address and since FreeBSD 8.1 I think it's multiple IP addresses or it might have been slightly before that and even IPv6 addresses so you can stick one application in a jail but a much more popular approach is that you stick a naked machine with nothing in it and you stick a jail on top of that which is a complete operating system in itself you just pop the whole user space in there and stick your users in there and then you're staging environments or another user is another jail and then if you upgrade you just build a new jail and you move the data over or you keep the data in the same place and it just makes life very simple it's file system virtualization and network virtualization and in FreeBSD 9 we're going to see the network stack virtualization even more drawn through up to the point of having an entire network stack per jail you can have a routing table or multiple routing tables in a jail you can have a firewall in a jail sounds very cool one more question yeah that's what it sounds like there are some differences but yeah this is not so much of a question as is an opinion I was thinking that really to me one of the great advantages of K FreeBSD on Debian is with their enterprise track today Puppet you can deploy these configuration management systems now to a FreeBSD kernel which may have certain features such as ZFS some of the great networking features that it has and you can do that without having to worry about a whole new configuration thing say with Puppet or it just provides a compatibility layer in an enterprise you really don't want to be messing around with too many user spaces even if you do have to compromise on the kernel I shouldn't say compromise there are a number of features in the FreeBSD kernel which are not in the next kernel for various reasons which may be technical I've mentioned the virtual network stacks and vserver is there and it allegedly works but jails is different jails are a very popular reason for people to choose FreeBSD ZFS is another very popular reason for people to choose FreeBSD it's very compelling for people who have vast amounts of storage needs and buildings full of storage to be able to manage that in the same way between Solaris and FreeBSD a number of people are choosing FreeBSD for many reasons but yeah alright let's thank the speaker again thank you