 The FreeBSD project is a community-driven project. The active developers do elect every two years a new core team of nine people responsible for deciding the project of our own goals and directions, as well as validating new committers' proposals and work on the project of our own bylaws. The FreeBSD foundation is a 501 U.S.-based nonprofit organization dedicated to supporting and promoting the FreeBSD project and community worldwide. Phoning comes from individual and corporate donations and is used to fund and manage a project. Fund conferences, developer summits, provide server grants for developers that's how a bunch of people are heading here. The foundation purchase the hardware to improve and maintain the FreeBSD infrastructure and publishes FreeBSD white paper and marketing market to promote, educate, advocate for the FreeBSD project. The foundation also represents a project in executing contracts, license agreements and other legal arrangements that require or recognize legal entity. To code its website, the OpenBSD foundation is an in-patient not-for-profit operation which exists to support OpenBSD and other related projects such as OpenSSH, OpenBGVD, MTPE, etc. It is a fundraising entity, it does not own any copyright over the code, even for sponsored work. It's responsible also for funding the data they need for the project, the icon, etc. and works solely through donations from users and companies. It has no influence whatsoever on the project itself. Also, the country of origin is kind of important. White may not seem like it at first. It actually is when it concerns the overall system. OpenBSD being based in Canada means that we are not subject to the US Crypto Export Regulation Act. Of course, the consequence was illegal to re-export OpenBSD from the USA very long and no US citizens were allowed to work on crypto of the project. Remember people, it is very important to direct to both foundations. Yes. So now, let's just jump straight into a very legal and controversial subject. At least. Yeah. What's the deal about that live exo thing? Have you tried to parse a net stat output with scripting languages? Well, having a programmatically possible output is very handy to write software on top of freeBSD. Quite quickly, and libxo is very useful for that. It provides the ability for the program to output some JSON or XML output. Well, having a kind of re-review does tools like LS really need to allow it to output. And it looks like over engineering, I speak. All scripting languages better than API to be able to deal with fights with them. So I don't see any relevance here. Well, to be honest on that, I had to search hard to find a usefulness. But I found one. So, how do you, with scripting languages, deal with some BXD extensions like TH Flags? All the languages are not aware of this. So you can have it through the libxo. Yeah, I'm kind of torn about this. Except it goes well. Can people learn something if they don't want to share it? Yeah, there's dash comma, seriously? Honestly, I have no argument about that one. So the funny story behind this one is we discovered it at Eurovision last year on someone else's talk. And everyone in the audience saw it was typo on the slides. But it is actually a thing. I have no argument for this one. I see. From my perspective, it is almost very over-engineered. So I mean, even just for the jail management, jail administration, for example, you almost have like 10 plus party tools to handle that. Why? I mean, why don't you have one good tool instead of 10, breaking it like different people and from different quality? There is a similarly huge list of tools for controlling different aspects of ZFS something based on art. Oh, sorry for mentioning this, but three firewalls, I mean, it can be very confusing to know which one to use and whether you can list them or not. When you do 3BSD, it's so very confusing. So from an outsider, I would say that IPFW should be the native firewall and it was written by 3BSD for 3BSD. So why keep IP filter and IPF which as far as I know is not going to be the same with upstream for you? So I have multiple things to say there. So for jail, the provided default tools in base system are in my opinion good enough to manage them. They are flexible, they are nice, they are simple to use and all external tools are mostly to provide some extra features like automated provisioning which I don't think belong to base because they can evolve faster and if they are available in the post tree, it's way easier to have updated version and remember that a branch will live for something like five years. So considering ZFS, the only one I have in mind is BE at ADM which could be missing in the base system which would allow it to have multiple boot environments. This one will, yes, end up in the base system one day if not yet. I haven't checked for a while what happened recently in that because it's useful but it's planned to. Considering the firewalls, yeah, true. IPFW has been developed by and forth for BSD but as long as we have people that are willing to actively maintain in older firewalls, there is no issue with that. So regarding PF, exactly. So regarding PF, it's true it hasn't been synced for a couple of years but it's still actively maintained beside what you're saying and it has features that are not yet available on OpenBSD which makes syncing difficult like we have ASMP support, VNet is another example. So remember it's all in our case about flexibility and yes, sometimes flexibility has a price. We can have multiple versions for something but it's for users. Well, in OpenBSD we like syncing. I really made these a few features here and there sometimes but ready to accept it if it gives us very clean, simple and self-contained. It is simply unsustainable to give you accommodating choices all the time and in general, complexity is the worst avenue of security which is one of our ground goals. Well, flexibility doesn't mean complexity. We also like simplicity in our case. Hi, Molly. No one's interested anyway, so... A tease, come on. So, you can say a few words about the fight system, but you move first. Okay, so in OpenBSD we support multiple fight system and so the native one being the original UFS that had evolved in the time so it's now support modern features like journaling, soft updates, trim, etc. We also of course support very modern fight systems which has ZFS as the first class citizen. Our file system support is extended to some random other fight system like MS-DOS fight system X2, 3 and 4 without journaling, NANDFS and more. What about you? Well, in OpenBSD we're still stuck with the traditional NAND5 system, UFS. That said, it has been extremely stable for us. That is for me, running OpenBSD in production since 15 plus years and never lost a fight. We obviously also support regular stuff like NFS, only version 2 and 3 because version 4 is very bright and we needed to do some stuff that we don't want in days like GSS API. Our auto mounter is still AMD from 4.4 ASD. Well, it's not very efficient, but it gets our job done. I1 would welcome more modern implementation. Regarding internet specifically, we have a native ice-pussy initiator implementation. It's called Ice-pussy-D. I wouldn't argue that fight system is not really where we're showing. We do have some updates, but we still have some bugs in that code path like a system code panic if there is a horrible fire failure. So, that's why standard OpenBSD installation has not come with a solid NAND5 system. Well, you really still have bugs in soft update nowadays? Yeah, but you guys have current, it's just too easy. It's hard to beat. So, on FreeBSD, under the hood, we have the GM layer, which is a powerful layer that provides us support for multi-paths through G-multipaths, encryption, GALI, GBDE, mirroring, G-mirror, network transport with G-gates. Also, it allows us to fake hardware errors and things like that with G-Nob. Very useful to test. We have wonderful support for ice-pussy targets with CTLD, with the cam control layer. It also includes high availability support, which is very nice. We have ice-pussy D and initiator for ice-pussy. On network fast system, we have very good support for NFS, all versions, server and client. Even PNFSE support is coming very soon. We provide 90 tools to deal with most of the storage devices. It includes SES devices with SES utils. Also, we can talk natively to SAS cards using native tools, not having to use hubs from LSI and other providers. As a client of storage, we also use the traditional AMD if we need to, but recently we have a new shiny auto-FS that happened. That's only speaking about the user-facing utilities. In general, I agree that the general stuff is a generally better solution, maybe except with regard to multi-path, which we do at those cars in Aero, with M-Path. That doesn't require any manual configuration, just looking at the hardware and figures it out. Regarding CFS, as you mentioned, it's with your kitchen sink. Is it a good thing? Is it a bad thing? Honestly, I don't have a strong opinion on the matter. It's truly a very nice piece of technology. There is no argument here. It comes with very nice features. However, the fact that it strongly recognizes an ECC network is kind of worrisome. Also, regarding red support on OpenBSD, it's generally in good shape, except for the red file discipline, which is still kind of a good problem. That's a bit embarrassing. Regarding encryption, we have multiple transactions on OpenBSD on top of the GM layer. We have Gehly and GBDE. Because they are on top of GM, then in a minute we can put any file system we want on top of it. For Gehly, since recently, for OpenBSD G11, we can support full disk encryption, the disk being decrypted by the bootloader using a passphrase. We also support, not in base, but developed for FreeBSD a file system of an encryption, something called BEFS, which allows to encrypt only some directories on whatever file system there is under the hood. The way we do encryption on OpenBSD is similar to how we manage red devices, hardware or software. By using the Bio-Control Management Interface utility, we offer a software encrypting discipline virtual device. So it is already familiar to people, because it's the same utility for everything. And the process is very simple, it's just one command. So, obviously we want support of full disk encryption, decrypted by the bootloader using a passphrase or a keys. That's ideal for non-interactive views, like we're using the USB dongle or anything. Well, by the way, on FreeBSD, using encrypted SWAP is very, very easy. You just append .eli in your FS sub at your device name, and then it's automatically appending. Well, our SWAP has been encrypted by default for many years without the need to do anything. So, it's my opinion that SWAP should always be encrypted. Your SSH or PGP priority would actually end up there at some point. We do have a system control to be able to disable SWAP encryption that is really needed. I'm mentioning it because that is an exception to the general OpenBSD rule, where security enhancements are enabled by default, where we can hardly disable it. And speaking of default settings, that's really something I love about this operating system. They make sense to me, at least, and are very well developed. We regularly have lengthy arguments within the project. Features should be available by default, and in which way it should work by default out of the box. That's how we come up with very simple demands. So, the network-related ones are actually a good example because they solve hard problems in simple ways. I've seen a few people already understand how networking works. For example, by just reading the configuration and the main page of BGP. Well, why is it true that OpenBSD has full features on the network side? For BSE it's also very full features on that side. Back to the base system, all those demand make your base system quite huge. Some of those tools could just be installed by ports instead of why having them in base. We consider OpenBSD as a general purpose operating system that provides the most useful number of services out of the box. It's an important design decision because it means that all these tools are developed together. A change in the kernel or library will immediately trigger some modification to these demons with the BGP. Also, anything that is part of BASE is what didn't, usually pledged, and follows our standards. The situation is totally different in ports. Also, it encourages code simplification within the base system. There will be a totally different thing in the D-Sport port of the port stream because things like runtime breakage may become unnoticed for some time. And for one, I'm very happy to have so many features in the base system. And the funny thing, actually, is that OpenBSD base system is still smaller than 3BSD's. So, it's quite frightening to speak about a huge base. On one hand, you strip down the base system, removing stuff like text info and pro. But on the other hand, you have three higher walls where you concentrate on having one way to do things. Well, the base system for us is also a current out-of-box general purpose system where a feature version of a given server can be installed from packages. There is no reason why it should blow the base system with a stool. If I take the example of MTA, I mean, if you need to run MTA, you will need to add tons, to depend on external libraries. Otherwise, you won't have a full feature one. I mean, held up connections and the virus connections and the spam connections, everything. That's something you will get from the base from the port stream. Why would I bother having a full feature HTTP server installed on my own storage, on my storage server? Of course, if a previous developer maintained that code, then it's another thing, then it could be in. That's the reason why we ended up, for example, with three firewalls, which is still not a big issue in my opinion. With the exception of a couple of servers which are closely tied to the kernel interfaces like iSCSI target layer and if SD, there is no need for us to provide full feature server. If we have, we do provide nubs so that we can build a stripped-down version of pre-VSD if they need it. I think that's actually a major difference between our operating system. We do not want to provide nubs for everything. We want to provide what we consider the same default and best practices to enforce our workplace. Also, is it a job to the operating system to provide embedded or stripped-down editions? An open-VSD-based installation is basically a complete forketing itself, meaning you have everything you need to continue developing the operating system, utilities, compiler and all. Similarly to pre-VSD, if you know VSD, iSC is a nice licensed spot or isolated in the source stream, so you can easily and safely make commercial products out of open-VSD without putting the actual responsibility of providing real nubs on us. Talking about nubs, doesn't make pre-VSD more like a tool kit to bring into the operating system than actual OS? No, not at all. Pre-VSD by default is a full-feature OS, as I said. In the binary form, we only do support the plan for pre-VSD by the ISOs. But keep in mind that pre-VSD is also widely used in embedded environments or inside the appliances. Both need lots of flexibility either stripping down the side for embedded or being able to replace one feature we do provide by their own implementation for some appliances. Also, we do encourage a lot of vendor to work closely with their herb-serminal case, meaning us. Yes, yes. Pre-VSD does encourage vendors to contribute and commit, but it wants to be that universal operating system like Linux and satisfy the maximum number of people. If you're looking from a different perspective, it would also say that pre-VSD does what your employer wants while open-VSD does what its developer wants. Anyway. Not totally false, anyway. I like the fact that I can have a functional problem-solving box in no time and without the need to install any third-party packages. For instance, I don't need to install a proper shell that I can work with. Do you have any features CSH or whatever? Being CSH has a different root shell, do you guys agree? If someone is willing to push a new feature or a new knob to improve flexibility, as long as it doesn't break pre-VSD direction, usability, we will accept it. It's not a problem. It gives us the flexibility we need in the base system and it's very nice to make pre-VSD usable in every single kind of niche usage for example, making a very seen-storage server that runs on RAM disk like we do in Gandhi. Which makes me think that I think that open-VSD does not support kernel module at all. I find those very handy for flexibility and as I can load our unload feature on demand or if I need it without having to rebuild the kernel or play with this control to enable to be able to interact with the kernel configuration, isn't that painful to tune your kernel on open-VSD? Well, that is true that we did remove support for loadable kernel modules, but we still have dynamicity thanks to our config utility. It's used to modify some part of the kernel without having to recompile it. Like device parameters that are usually hard coded in the kernel can be changed, added or removed. It does not allow you to inject code into the kernel, but it gives you the choice to enable or disable existing code. To give you a simple example it's often used to disable ULBT which is the USB printer support to make a printer using cups and USB actually usable by open-VSD. Okay, let's virtualize a little bit this talk. On 3D we do support running Linux binaries, not only via the Linux simulator, also called Linux simulation. Right now we do support Linux i3886 and AMD64 binaries. There are patches available to support Linux ARM binaries. We also do support running old 3BSD binaries on newer releases, meaning that if one wants to create a gel to run 3BSD4 using binaries on 3BS11 it works out of box. On the virtualization front we we are very well featured. We do support native virtualization via Behive. It has many nice features. We have a Netmap interface support, VNC server support it can run almost any operating system guests as long as it supports virtual and EFI. It is also fully sandboxed via Capsicum. We also support external virtualization mechanism. We can run natively DOM0 or DOMU for Xen or we also have virtual works in the Post Street that works on 3BSD. Having Citrix people working as developers does help. I think it boils down to the fact that you guys made the decision a long time ago to not fuck with the hardware as much as possible, but instead let the manufacturer do it instead concentrate on something else. On OpenBSD the situation is a bit different. We prefer to try and convince the vendors to open the specification to let us write our own drivers. Your approach is probably more pragmatic, that's for sure, but as you probably know by now we like to be in control of the operating system. So sure, everything is black and white of course and so this is to be taken with a ground of granite salt since there is a lot of cross-pollination in the project and we do use some parts of your vendor written drivers like iX for example. Well being open to vendors in my opinion is a pragmatic point of view and does not make us lose control of our source at all. Actually we have very good relationship with plenty of them. They are committers running through our usual process to recruit new developers. We review the code they submit, we even add some time. It's not unusual to see some vendor committers continuing to contribute to free BSD way after the live the said vendor. So back in virtualization because that's what we are speaking about what is the situation on open BSD? Well let's start with VMS since it's been mentioned a couple of times already. Currently it can reliably run open BSD, net BSD some Linux distribution and we assume maybe 2 BSD by now I've only tried. It provides a very nice user interface with VM control and since it's true that and pledged breaking out of VM monitor means ending up in the chute with obviously very limited list of allowable system calls. The other virtualization technology that open BSD supports is sent for V logical domains so known as LDOM it's hardware virtualization that means the resources are partitioned directly at the hardware level it's supported on a smart V9 processor it's a pretty secure design since there is no software hypervisor involved the processor itself run in hyper-privileged privileged execution mode so it can natively run any smart hardware system that lives into it. So we were speaking from the beginning about our project in thermal but what about rationship with the external projects in general for FreeBSD most upstream are happy to receive FreeBSD rated patches and integrate them even big ones for example doing an upstreaming patches to Libreface was a very easy process they welcomed all of them and they even tried to set up a CI so that they are not breaking our usage on the GNOME front so you probably know better as a GNOME committer yourself we don't I don't deal with the patches myself directly we have a good relationship with our JLIB maintainers who came to us to ensure that JLIB is working correctly on FreeBSD, on the BSD in general by the way they even set up the GNOME CI on FreeBSD to ensure that every thing we allow is fine as possible yeah I guess we pretty much shared the same experience here some streams are more open than other to non-linux contributions in general they are pretty happy to integrate our patches and sometimes they actually learn a thing or two about portability it is true that a few identified people within the free software community take some pleasure in bashing anything that is not GNOME or Linux but these are far from being the norm so fortunately for the ecosystem sometimes upstream can also be very close we have openBSD developer we are also developer at GNOME XSE, Moseal, LibreOffice etc of course with openBSD being the upstream for server software which I mentioned already on this stage etc also some application can be very complex to port, it is important to be able to interact nicely with the stream because sometimes you do need their help and one thing starts crashing when our debugging tools come into action so I will not go into the details of such tools which are probably similar to yours I just mentioned that we are building the entire database system with debug symbols and that we are thinking about doing the same for port or at least to identify the port so we are going to do that with the GNOME NGTK so freeBSD is pretty well served for debugging by default the base system we have catrace trust to be able to track what an application is doing in particular when debugging a capsicumized application it is very useful to have catrace to value or the capability an application might be missing if any finally we now have detrace support in the base system which is a very useful tool to be able to do some tracing when building the freeBSD kernel for example we build it with all the debug flags which are converted to the CTF format and then they are all detraceable by default to help debugging we also have by default the debug flags activated when debugging and that was played from the binaries so that in embedded environments you don't end up with them LLDB and GDB has been configured so that they know where to figure out the past to those debug flags concerning the port 3 now lots of applications are detrace aware but the port 3 itself is still not built with the debug flag yet it's work in progress the goal is to also extract the debug flags by building for that we can provide debug package so you have debug flags whenever you need it but not when you don't need it well debugging is another area that has a lot of improvement and development lately on GSD our GDB the kernel debugger just got basic support for CTF that has nothing to do with capture the flag once being included in two boundaries CTF in a compressed type format will provide a subset of the information on the work debugging sections like definitions of data type and functions used by debugging tools we also have a CTF dump and CTF conf implementation thank you MBI and we can dynamically activate the kernel providing using detrace like post so we have the background for detrace which is great and by the way I really plan to import those BSD license versions of CTF dump and CTF conf so it looks like you are slowly getting there for our tracing so both project now are going to have both nice debugging capabilities that's it another difference between open BSD and free BSD is regarding authentication and authorization so on free BSD for the authentication we do use spam actually the open spam implementation developed and maintained by a free BSD developer which is compatible with the spam specification it gives us access to a lot of various external modules even for most of them we would prefer relying on our own implementation the nice thing in that it makes it simple to port common software that already supports spam well BSD is what we use on open BSD it originally came from BSDIS BSDOS one of the main difference between BSD and spam is that spam modules are basically libraries which must be loaded into the application BSDOS modules are actually separate applications for helpers located under the user in the exact port directory and that are run as separate process from the one with anti-KM which allowing them to communicate over very simple like scenarios that means we basically never expose the credential store to possibly buggy software so actually the traditional privilege separation model that we use on open BSD while still being able to provide a different way to authenticate to adapt current world UVT radius so quite a pun maybe a bit more flexible and way more pun we found so there are a lot of different authentication modules really available it usually requires a little bit of privileges to authenticate applications using BSDOS they need to be in the off group to be able to run the helpers looking to open SSH for example most of the recent advisory I mean not most but a lot of them are more pun related well in the case of open security advisory maybe it's also related to the fact that the upstream meaning you is paying less attention for obvious reasons you just stated about the PAM code itself but it's true that the PAM API is not simple to use and is also very error prone but in the open PAM implementation while it's compatible with the official API it also provide plenty of extensions to helpers that simplifies adding support for PAM authentication in a less error prone manner anyway for name services we do use NSS which provides us a lot of flexibility as well through its modular nature not that our NSS API is not 100% compatible with the GNULIP C1 but we also provide a NSCD demon which can cache name services responses for users but is not limited to that it can also pair from the request which means the modules are no longer loaded into the Lipsy but in a dedicated demon okay well regarding authorization and virtual system users we only have support for traditional by the NSS OpenBusy does not use NSS so nonsswitch.com for basically the same reason it does not use PAM we do not want dynamically loaded modules to play game in our Lipsy or resolver we do have support from getting users out of an LDAP server thanks to our YPLDAP utility actually I see that you guys imported it some time ago and I'm interested why I mean you guys have NSS on that isn't that good enough for is it to satisfy flexibility to be honest I still wonder why we have imported this YPLDAP tool but I mean it doesn't hurt and as far as I know I got feedback from at least one university that was happy to see it happen so that they could have a simpler steps to migrate from our NSS to LAP so why not so I guess that those things consider it's pretty obvious that my BSD sucks less than yours I have to disagree on that one and for me it's clear that my BSD sucks less than yours that's it I think there are areas where we both sucks equally I mean what is the state of your wireless drivers that is very true we both suck on some aspects well let's say this presentation was done on a free BSD laptop you mean you're probably not using a map or as much as we like to make fun of each other we are not only sharing bad things no no no I think that cross pollination between our two operating system works quite well we've changed a lot of things and it doesn't make sense to list everything here well in my opinion OpenBSD has an important role in the open source ecosystem you guys are talking very important project which would probably have never happened otherwise the most famous one being obviously OpenSedge but I really like how open you are through portability for those software given the extra amount of work it gives you if I think of OpenSMTPD T-Max, Mandok, SNDIO and many others they are a very good example of that you are also teaching upstreams about good and secure coding practices which is a very important thing to do and from where I stand I think that free BSD is important in the global ecosystem it's a real enterprise operating system and I think it's slowly filling out these both left by Solaris it bundles some amazing pieces of technology that's for sure and in some Maria is still on the edge of innovation some very large entities obviously use it and thank you for FreeBSD, a lot of people have been made aware of the BSD community in general so for me it's a very good weapon to make people aware that French operating system are certainly not lagging behind Linux for me FreeBSD is a wonderful operating system it's very flexible and attractive for most all use cases the project is very open and everyone from vendors to individuals can have their place in the project while there are a lot of vendors involved and that contributes to FreeBSD the project remains completely community driven and individuals can easily find their place in the project, I'm a good example of that in my first two years I've been able to drive into the project and change made some very important modifications including taking being part of the direction of the project itself OpenBSD is a small project but I'm very proud when I see that in some Maria a small amount of hackers can compete with a huge project like FreeBSD and sometimes actually do delivery things ahead I like to say that we do serious things without taking ourselves too seriously you guys say or performance stocks we say that your security stocks I suppose there is some truth in both stereotype I see OpenBSD as kind of running to better and better up from new technologies that is not afraid to break things a sort of destroy to build approach I really encourage people to try and use it as a power user or developer not just installing but really try using it, I've been surprised at how many people actually have a misconception of OpenBSD even within the BSD community itself in my experience besides the obvious benefits OpenBSD is known for, practical security and all, it has been one of the easiest and best documented operating system that I've ever used and I see its simplicity as an art form thank you very much thank you very much all and I sing inside for Monotary Herg, BSD Herg I love you anyway Baptiste thank you