 Next up, Steven Chamberlain will be telling us what he's done on Debyn K3BST since the last EBCONF and also some example of people actually using K3BST in production. Thank you. Okay, so you know what K3BST is before I start? Put your hands up if you know what it is. Yeah, so I don't really need to go over that much. When are you actually using it for things yet? Oh yeah, that's one more than I thought. Yeah, I've had a lot of people asking questions about K3BST, but also about me because I generally don't talk much about myself, but we have time. I'm from the very north-east of England where there are very few DDs around. Not many major IT companies, so I just freelance. I'm a developer and a systems administrator. K3BST sounded interesting to me five years ago. It just seemed something really cool and different. I thought I would try it out. As I started to find bugs in it, I actually had some fun fixing those and decided to keep going for another five years. Other questions I've had, people asked me why they should run K3BST or why does Debyn need K3BST and what's wrong with just using Linux. I'm not going to answer these questions because they'll have a negative connotation to them. I'm not saying Linux is bad. It's very good, obviously. Many of you seem to like it. I don't want to sell K3BST to you because if you think it's useful to you, you should already know this. People will just think, oh, I actually do need to run a K3BST kernel for some reason or I have some application that can only run on the K3BST kernel. I would like all the good things that come with Debyn as well. Why I personally work on this project and some of the others before me, Santiago Vila said, because we can. Well, Debyn is really well-organised to allow people to work on whatever they want to do and mostly keep out of each other's way and produce something that's the combination of everyone's efforts in different areas. Debyn always offers choice to its users, so we carry whole different desktop environments in its systems, different window managers even. Every small detail, there is a choice within Debyn for whatever the user would like to use. Many Debyn users love Debyn for this reason. Let's offer different kernels too. It's also very educational working on K3BST. I only had about two years of university studying computer science, which is not a lot of practical knowledge, I think. Diving into something like K3BST, where one moment I'm working on some crufty pill script, and then the next minute I'm trying to build up in JDK or something, which is a huge C++ project. These are all things that you can only really learn by doing. I've learned a lot in five years. Some advantages that K3BST has for Debyn is that it's a good QA. We find interesting bugs, quite a lot of them actually. Somewhere in Debyn packaging, maybe making wrong assumptions about what will happen. Test suites often make the assumption that something... Many tests are just broken. People seem to just run the test and then whatever the answer is, they code that in as the expected result. Having software be able to run on very different systems is a healthy thing, I think. It might not make sense. It might not seem to make sense if 99% of people just use AMD64 and Linux. Every now and again there's a new cool platform where Debyn would be really nice to have. The more practice we have at porting to new or old platforms, then the more agility and flexibility we should have in our toolchain packaging to be able to support a new architecture when it comes along. In free BST kernel itself, there are some cool things like BST jails, which were around before. It's quite similar to SystemD N spawn, I think, but also has some... It allows to give an IP address to a container, like OpenVZ. If any of you remember that, I think LXC is doing a similar thing now in Linux, but free BST has had this for quite some time. It's quite mature there. There's extra security features like secure level, which some people are interested in having this in Linux, but we already have that in key free BST. The firewall is good. That's the one from OpenBSD, just a very slightly different implementation. And we already had CFS. Debyn can offer some nice things to the free BST user. They could come to Debyn and we have a nice collection of software packages that are well looked after. We have very strict policy on how the package can be... What the package can do. DFSG. Upstream free BST has different opinions on what they will allow to put in a package. And yeah, Debyn has a lovely community behind it. Right now, if you're running kfbst weezy, and some people still are, you should probably upgrade, because since we're not part of the LTS, that's end of life now. You should upgrade to the new suite, which is called Jesse K free BST. So it's not just Jesse. You have to edit your app sources and change the suite name to Jesse-kfbst. And then app get, dist upgrade, reboot, and hopefully everything should be just fine. Jesse K free BST is not an official Debyn release architecture, but it does have security support, because we simply take the packages that are uploaded to the main security suite, and we have a security build daemon that will just build these packages for kfbst as well. That only leaves parts that are kfbst specific. We look after those too. We package upstreams errata and security updates. Now, if you want to install this fresh, the difficulty is that we haven't been able to build CD images in the correct way for an official release. We have some things that are in Jesse K free BST proposed updates, and some packages that are in Jesse K free BST. The CD image building tools don't usually build from these two sources at once, but maybe we could... Yeah, this is still to be worked out. I have some unofficial install media around if you do want to try, either ask me or there's a mailing list post I can show you. So actually using kfbst, this laptop is running kfbst. I have Firefox, BLC, console, everything I need. 3D graphics is working now in Jesse. It wasn't always the case. We relied on the visa driver in Weezy, but now have these KMS drivers which have been imported from Linux. They mostly work okay. I'll also mention that kfbst doesn't have system D. That's because it cannot be easily ported, and it's sort of a moving target. We're unlikely to go with it, but upstream free BST is interested in new init systems. They have multiple projects going on to look at alternatives like OpenRC, and NOSH is something that may be able to take system D init files and use those as is, a sort of compatibility layer for systems that want to use system D unit files, but on platforms that don't have system D. I've known many people who use kfbst for a small firewall router box because of the nice network stack in free BST. It's well known that some companies like Yahoo, Netflix, WhatsApp even powered their systems on free BST for some reason. Some people feel the network stack is better or easier to extend for their particular application. The pf firewall is very good. It has a lovely configuration syntax. There's also carp, which comes from OpenBST. That allows for a high availability setup of multiple firewall systems, and if anyone goes down, the other one should just take over automatically. I personally have used kfbst to set up wireless access points, a network of them bridging between a wired VLAN and a number of nodes which are running kfbst as wireless access points. This is super easy to set up. It's basically just running if config in the right parameters, and if you have the appropriate hardware that can support running in master mode, then you can set up a really easy wireless access point that way. The advantage of running Debian on your access point is that you can install any Debian-packaged software on it, so you can run a SSH server on your access point, log into it, see what's going on, look at what nodes are connected to it, signal strength of those. I even wrote a sort of graphbiz script that would show all the nodes connected to different access points in different buildings to see where devices are located and their signal strength. Also, all the system deployment tools in Debian, such as Puppet and Ansible, you could actually use those to configure your wireless network if the access points run in Debian. File servers are popular. I use kfbst for this. Some of the kfbst users have set up file servers because ZFS is really nice. It compresses the files on disk. It's on checksumming to assure integrity of data. Snapshots are brilliant. I will talk about those next. ZFS was based around the principle that hardware rate controllers suck. They limit you in what you can do and run a proprietary firmware usually. If this is all implemented in free software, then you can do things that a raid vendor would not allow you to do. It's very easy in kfbst to adjust the configuration of your raid on the fly while it is online. You could upgrade an entire raid from small disks to newer, larger capacity disks without any downtime and expand into that space. Some raid controllers will allow you to do that, but some won't. We'll do an awful lot of resyncing and things. Resyncing is much faster in ZFS because it only resyncs the allocated data and not the whole pool like Linux MD would do on a block device, because Linux MD doesn't really know if blocks are in use, whereas ZFS does, and it will only need to resync those ones. ZFS snapshots are a good thing to have on your backup server, especially if it's rideable by everyone. If you write all your data on a backup server, then any user might delete things from there. People sometimes delete their backups by accident. Malware might corrupt your backups in some way. Even on a desktop system, it's useful to have ZFS snapshots. If you had some cryptolocker malware, you'll want to revert to some older version of your files before they have malware in them or whatever. Snapshots are slightly different from incremental backups in that you can delete intermediate snapshots. Generally, you don't care about having a backup per hour of something you did like two years ago. You just care that you can retrieve this thing that's from about two years ago. But if you're doing day-to-day work, you don't want to lose too much data in case of a disk problem. You really want to be running snapshots often. You can run them as often as every hour if you want. You always have a recent backup and then just delete older snapshots to free up disk space. That way you have a range of time periods you can revert to. I was going to talk more about Z-Build, but I haven't really finished it yet. It's a mess. I don't want to show you it because it's something I began in Shell and should have rewritten already in a real language. I have a server that runs the bootstrap quite regularly and then snapshots the result. At all times, I have a snapshot of a successfully bootstrap SID. You then clone a snapshot. This is copy-on-write, so it's very efficient on disk space. You have a copy of a fresh SID shrewt. You can unpack a Debian source package there and install build dependencies. What I would then do is snapshot again because quite often you want to build something more than once. There are some people who want to test for reproducible builds maybe in the room. So if you have a snapshot of after having unpacked source and installing build depths, that's actually quite slow. If many packages are small, unpacking them and installing build dependencies takes time. If you're going to be building something more than once, it's nice if you can just snapshot the result of that and reuse it. You can then trigger as many builds as you like. You could make some small change first, like upgrade to GCC6 before running the build again and then compare it to your other build with GCC5 or see if it builds with GCC6 at all. You could try other variations in the environment between successive builds and look for issues of reproducibility. I have this running already. There's no time to show you, but jenkins.k3bsd.eu. There are some jobs on there. Some of them are just checking out upstream software projects and seeing if they still build on K3BSD. The idea of this is that I don't want maintainers to pull a new upstream version. Find out it doesn't build on K3BSD and then require help fixing it. I'd rather catch that early and then sort of cut the Debian maintainer out of the loop so I can just save them time by getting it fixed upstream before it reaches Debian. A project that started last step on was RebootStrap. We are multi-acting our tool trains to make it easier to cross build from K3BSD to other architectures and vice versa. Something new that will come out of this soon is K3BSD ArmHF. We're hoping to make this a thing soon. Recently in CID, K3BSD 10.3 just landed. There's a really cool downstream project now called UbuntuBSD. It's an Ubuntu user who wanted some K3BSD but didn't want to leave Ubuntu. It's not an official Ubuntu project but it's already ten times more popular than ours in terms of users. They're really great. They are finding bugs before we hit them and send patches to upstreams and to us. So thank you to them. Thank you everyone in Debian who's helped in some way, K3BSD, DSA team, security team for all the infrastructure, FTP masters, KB working on the installer. Thank you all for making it really fun to come here and work on free software. Thank you very much. Do we have time for questions? Very good. If you have questions. You mentioned that PF is working in K3BSD but I failed to use PF log which is quite useful for debugging why firewall rules do not work as one expected them to work. Yeah, PF log needs work. But the rest of PF is fine. If you have more questions, I'm going to start hanging out in the IRC. I never really used IRC but I'll have a look in there to see if anyone has questions if you're either here or watching from home or wherever. Pop in IRC. We're a nice group. We'll be happy to chat with you. Thank you very much. Steven C99. Thank you very much. We have to close the session because there's another one that's just about to come in running. Thank you.