The TrueOS Difference
Moore, Ken
Since the TrueOS project was started in the middle of 2016 as a re-focus of the PC-BSD project, we have been seeing massive growth in our user base and the number of active contributors to the project. This session will go over the differences that TrueOS brings to the table compared to PC-BSD/FreeBSD, the reasoning behind those decisions, and how those changes are currently implemented within TrueOS. The TrueOS project was started in July of 2016 as a re-focus of the PC-BSD project. This change allowed us to address several key issues that we were having with using FreeBSD releases as the "core" of PC-BSD. Since then, we have seen significant growth in the use of TrueOS not only as a Linux-desktop alternative but also as the foundation for server-focused appliances. This session will be going into detail about the issues that necessitated the change, the attempted solutions to those issues, and the final changes that are seen in TrueOS today.
 Alright, so before we get started, I just have a few quick questions that I always like to ask people before I ever give a talk like this. First one being, since we're at a BSD conference, everybody who uses open BSD, raise your hand. Everybody who uses net BSD, raise your hand. What? Nobody? Dragonfly BSD. And FreeBSD. Other. You. Okay. So, I just generally like to do lots of little quick polls for people right before I talk. Usually, I do give these kinds of talks at Linux conferences where nobody's ever heard of BSD, so I have to kind of explain what it is. So I always have to explain, okay, what FreeBSD is and how it's descended. That's fine. Since we're at a BSD conference, though, I can be a little more specific. So I assume most of you have heard about TrueOS before. Am I correct in that? Yes? Yes? Okay. Other hands. How many of you have not heard about TrueOS? Good. I don't need to explain myself then. Oh, wait a minute. Do you? Okay. You're good? Okay. So I don't need to go into too much detail. I mean, I'll give you a little bit of detail in here, but I don't have to go into gory details or whatever if you're already familiar with it. How many of you have actually used TrueOS at one point? All right. How many of you used TrueOS right now at the present time? Okay. How many of you ever used PCBSD? A few of you? Okay, good. That gives me a rough ballpark of what kind of audience we've gotten. Now, how many of you are interested in TrueOS but haven't heard any of the recent developments? Okay. Like the stuff that happened, what was it yesterday? Two days ago? Yeah, the blog post that came out a couple days ago. Are any of you familiar with that already? Yes? No? Okay. Well, I do go into a little bit more details on that at the end of this talk because this is kind of what this talk was going into is why what was announced is actually what's going where we're going going forward. So this will lead into that and explain the background of the project and why we're going where we've been heading and just haven't told people until now. That's always fun. And just for my own benefit, completely unrelated to that stuff, how many of you used the Lumina desktop? One of you? Oh, a few of you. You mean regularly or how many of you used it? How many of you used it within the last month? Okay. A lot more of you. Good. Now, are you using, those of you that are using it, are you using the latest release version on FreeBSD, which I think is 1.4.0? Or are you tracking the newer releases from the source repo, which I think is 1.4.3 at the moment? FreeBSD packages? OpenBSD packages? Yeah. Okay. That's kind of what I expected. What version was in the 1.8.0.3 TrueOS? 1.8.0.3 TrueOS. Yeah, I think that one's a little older. That's 1.4.1, I think. All right. Sorry, I've got two minutes. I'm trying to kill time. Anyone know any jokes? I try to be a comedian, but everybody just laughs at me. I don't get you every time. Yeah, almost there. Does anybody know how the recording system works? I heard it was supposed to be recorded, but do I have to stand right here? I've got the mic. Oh, this one. So I need to stand over here so people can see the slides. Over there? Okay. They're not recorded. Okay. So do you want me to stand over there out of the corner or something? Like over here. Yeah, that's what I was going to say. So if I'm in the corner, hopefully I'm not covering the slide. Yeah, that's true. I should probably post them somewhere then, shouldn't I? Yeah. Okay, I'll try and stand here. I tend to pace, but I will try to remain fixed. And that took the rest of the time. So, all right, welcome to my talk. This is the TrueOS difference. For those of you that aren't familiar with me, I'm Ken Moore. I work on the TrueOS project. I was part of the PCBSD project back in the day. I was one of the founding members of TrueOS when we made the name switch. And here to talk to you a little bit about it, shore up some things that people might be confused about, you know, enlighten people that weren't aware of things. So this is just a quick, very rough outline of what we're just going to go over today. I'm going to try and do a very quick history of TrueOS just to give you all the context of why we do things differently than FreeBSD and why we've decided to focus on these differences. And we'll go into changes from FreeBSD because TrueOS is based off of FreeBSD itself, but we change a number of things. And so I'll go into some of those. And then I want to go into some of the next steps, stuff that was mentioned in the release announcement a couple days ago, and go into, with all this context, I think a lot of that will start to make a lot more sense for why we're changing directions. So first off, PCBSD. Number of you said you were familiar with it, had even used it. So I hopefully don't need to go into too much detail on this, but it was started in 2005 by Chris Moore, who is my older brother, it's not me. And he started in 2005 as a desktop focused version of FreeBSD release, and the original version of PCBSD was based off of FreeBSD 6.0. He gradually started creating and adding utilities to PCBSD at the time, specifically for shoring up some of the weaknesses. PCBSD was based off of KDE 3. So he created a new network manager in QT 3 to go along with KDE because the KDE network manager wasn't working properly with FreeBSD, things like that. So eventually he created some utilities such as PCSys install, which is a scriptable installer for FreeBSD rather than the text installer. PCNetManager is the network manager I mentioned a moment ago, and there's a number of other ones. All of the utilities that he created for PCBSD were submitted back to FreeBSD as ports. I believe most of them appeared in the sysutils category, and they were all PCBSD dash something in the ports tree. Gradually he started delving into adding and customizing the FreeBSD ports themselves on a regular basis because he discovered that many of the ports, the build options for the ports were not designed for desktops, like they had all the graphical stuff turned off, and then when you run it from the desktop, you wonder why things don't work properly. So he had to start building his own ports tree and building his own packages with different flags turned on just so it would integrate properly. So he started maintaining a fork of the FreeBSD ports tree. I joined on the team a little bit later after that, and PCBSD kept going till the 10 series, FreeBSD 10. And then in the end of 2015, very beginning of 2016, we decided to make the plunge. We had always been based off of FreeBSD releases for PCBSD. But then we started, it's like, you know what? Every time FreeBSD release comes out, we would determine that it was already at least a year or two obsolete for modern laptops. It would never work with stuff that had come out within the previous year or two. So since we were based on releases, even though something was brand new for us to the rest of the community and the consumers, it felt like, oh, that's old news. It doesn't work on anything new. So we started rolling builds of PCBSD using FreeBSD current instead of FreeBSD release branch. So I think it was December of 2015. So I put the end of 2015 there. But by December of 2015, we actually had a rolling build of FreeBSD current at the time, publishing pre-release images of FreeBSD 11.0 from the current tree. As part of this move to current, though, we also started using some new systems in FreeBSD which were planned and scheduled by the FreeBSD team for release in 11.0, namely package base. So this is something that FreeBSD still doesn't have in the 11.0 series, and they're still talking about whether it's going to get put into FreeBSD 12 or not. But PCBSD or TrueOS has been using package base for almost two years now. We've actually been using it and testing it and committing fixes to it right back to FreeBSD. At the same time, though, Joe Maloney came on board at the TrueOS project, and he was very, very interested in this new system called OpenRC to help replace some of the service management systems on FreeBSD. Chris and I had been looking at a lot of alternative service management systems like NoSH, LaunchD. There was one or two other ones as well. We've been evaluating them for a while, trying to find something to help make things boot up faster and easier to manage. So when Joe Maloney came by and he's like, yeah, I actually have a build of OpenRC on FreeBSD over here, we were very interested and we started running some builds with it and testing it and toying with it for a while. So in 2016, early 2016, after we had been rolling these current builds of FreeBSD for a few months, we decided that, okay, so much has actually changed underneath the hood from these rolling release builds to the release builds of PCBSD that the upgrade path was already completely shattered and broken. There was no way for somebody to go from a release of PCBSD, I think 10.3 or 10.2, was the last release of PCBSD. And then we had these rolling release images, but there was no seamless upgrade path. It was a really complicated mix of hacks and manual commands and it got ugly really, really fast trying to move to these new systems of package base and OpenRC. So we decided that at that time, okay, so much has changed, we've ripped out so much of the old system that was there for PCBSD and we've put in so many new subsystems, we didn't really feel right calling it the same thing anymore because we were also focusing from the true OS perspective on different systems. We weren't just doing desktop stuff anymore. We were now talking about configuring FreeBSD. We were tinkering with the FreeBSD underlying system itself. We were no longer just being a desktop built on FreeBSD, which was the point of PCBSD at the time. So we announced that the PCBSD project was ending and that the true OS project was the next evolution of it to take its place, much like a phoenix rising from its own ashes. So that was the beginning of the true OS project in early 2016 and it really had a very different focus. First step is that it was consumer focused instead of desktop focused. So we weren't just doing a build of FreeBSD and then slapping a desktop on top like KDE4 was what we were using at the end of the PCBSD days. We were no longer just a desktop distribution. We were literally a customized version of FreeBSD, implementing a lot of changes in FreeBSD that FreeBSD, people who are following FreeBSD releases wouldn't have for another year or two depending on when the next scheduled release was because we were being based off the current branch of FreeBSD, not the release branch of FreeBSD. So our timetables were greatly accelerated from standard distributions of FreeBSD. We basically moved from a downstream consumer of FreeBSD releases just using whatever FreeBSD gave us and actually moved into an active tester and contributor back to FreeBSD because we were providing FreeBSD developers users and people that were testing their changes very quickly after they were committed to FreeBSD head and providing active response right back to them so that they could get things, issues worked out and resolved well before the FreeBSD release process ever got kicked off. One of the other ways that we would do this is actually emerging FreeBSD developer branches into base ahead of time. If they got bogged down in some kind of issue either in fabricator or something, we would actually merge those branches and work with that developer to get their changes put into base ahead of time so that they can prove to the FreeBSD project, yes, it looks like it's a drastic change, but don't worry, it still does work very well. We have live builds, see if it works fine. So we would do stuff like that and we were very instrumental, I won't say exactly very instrumental, but we helped with that considerably with regarding the new graphic stacks for FreeBSD involving the newer Intel drivers and DRM next stuff. We were pulling those in and using that and providing feedback on that very, very early. So okay, that's the end of the history of TruOS. That kind of takes you from PCBSD up to TruOS at the current time. Do you have any questions on history before I go into other additional differences from FreeBSD? Just showing how we kind of move from a desktop distribution of FreeBSD to basically a customized version of FreeBSD current in the back. What do you say you couldn't really upgrade from rolling release? Does that mean every time you wanted to upgrade you'd have to wipe and retake? No, no, no. So the problem was switching trains, if you will. We couldn't go from the stable version to the rolling release version. Once you were on the rolling release version, you could upgrade and stay on that fine, but there was a hard break between the two and we couldn't find an easy and automated way of automating that. So that was a very clear logical break between the PCBSD days and the TruOS days as we can point to that because there really was no easy bridge. That's your watershed. Yeah. It was a very clear defining moment for us. Yes? It sounds like you're pushing stuff a lot faster than FreeBSD, you're pushing more stuff in quicker. Do you have any special methodologies to make sure that it wasn't breaking stuff? You and that testing? I'll get into that in just a second. Yes. So, okay, yeah, that's just the general history. Let's go into a few more of the differences now of what's different now in TruOS compared to FreeBSD because I've said FreeBSD current many times. Obviously, there's differences there between FreeBSD current and FreeBSD release. That's a given. But what does TruOS add to FreeBSD current and what do we do differently? First step, release engineering. Obviously, since we're based off of current, we're no longer following FreeBSD's release schedule. So we had to start providing as a project our own release engineering, our own release schedule. So we've tried many, many different types of schedules for releases among the PCBSD and TruOS days from weekly rolling release images to monthly images to mixtures of long-term support releases. And what we settled down on is actually one that works really, really well for us right now. And that is a six-month release, which we actually got the idea from OpenBSD. For any of you OpenBSD guys here, thank you. It was a great idea. So that every six months, you get a stable release. That's what we call it on TruOS. We have two branches. We have stable and we have unstable. So stable is a six-month release. There are no changes to base or ports in that time unless there are like major security issues. That's actually why we issued the 1803 release of TruOS halfway through our six-month cycle in response to Spectre and Meltdown and stuff like that. It's significant enough we needed to push out another release image ahead of time. This, the reason we had something like this was this was perfect for derivative products or appliances. We had a lot of people that wanted to use TruOS either on their servers or build their own little appliance off of it. But if you're having weekly updates to it, that's very, very disruptive to end users, specifically enterprise users that expect it to be like a static appliance. They don't want it to change. So why does it keep trying to automatically change things? So stable releases were perfect for that because six months is a long enough period of time that it's still easy to support it for us because we're a much smaller team than FreeBSD. It gives us a smaller window. It's like, okay, yes, we will support that stable version for six months. And then it's also long enough for the end user because it's like, okay, once I install it, I don't have to worry about it for six months. Unstable branch of TruOS is much more of our rolling release branch. So this is where we released much, much more faster. We would do it sometimes once a week. We tried to shoot for once a month, but we weren't necessarily on a fixed schedule. So we told people it could be anywhere from every week to every month for a new image of unstable. But what was unique about unstable was that it was the combination of unstable base and unstable ports. So if you wanted the new applications and stuff, we kept telling people you have to go to unstable. That's where we do all the new builds and stuff like that. But the unintended consequence of that was that you were also getting all the new base bits from FreeBSD current at the time. So both of them were rolling in sync at all times. All right. Any questions about release engineering before I move on? So this is what TruOS is using right now. We still have this, this is our schedule and this is our release engineering. As part of our release engineering process, we have quality assurance processes. We actually have fully automated build systems running all the time. And as part of that, we actually have a bunch of QA procedures built into it as well. So we try to catch things when building the full ports tree, for instance, we have a list of what we call essential packages to basically alert us if one of our automated builds, one of these packages fails to build. It's like, okay, something's going on in the ports tree right now. When all the flavors for Python got put in, needless to say, we were getting lots of alerts from our build system because Python 2 and Python 3 were some of our critical ports and things were no longer failing to build, were failing to build for quite a while. So we have things like Python clang. Because we do have the desktop side of TruOS, we add things like Firefox into there and a few of the other browsers, Chromium. So again, if one of those doesn't build, we consider that a bad ports tree and then we have to work on the ports tree and then trigger another build until we can get a good ports tree, a good build before we would consider releasing it. By the same token, we also check things from base. So bootability with the latest FreeBSD base, we would check the bootloader. We would check all the base packages and make sure that we could update between one set of base packages to another set of base packages. Since it was still highly experimental from FreeBSD itself, we did a lot of checks there. Plus, we did a lot of manual checks. So we would always install many times, either into virtual box instances, onto laptops, onto desktops. We would try to manually install and test these images in several places before we would issue a new set of updates as well so that we could actually get the hands-on test. That's where we would find out, for instance, if, oh, yeah, the driver is there, like, for instance, the NVIDIA driver. It's there, it built, but, oh, wait, NVIDIA added another version of their driver and the latest driver now drops support for all these cards, so we need to try and detect and fall back to, you know, older versions of the NVIDIA driver for particular systems and, you know, things to watch out for. That's where, that's the phase where we would have noticed things like that because we were actually running it on physical hardware and we ran into some of those things. Make sure that networking works in various types of situations, check that removable devices are working, things like that. Yeah. The automated checks is mainly just for builds. Does it compile? Do we get a package out of it? Using, like, the new versions of Clang and things like that, that was not actually running it. Running it would be part of the manual test where we would actually physically install and run a whole lot of things. Yeah. Mainly because we tried to pick certain packages as, like, bellwether packages for entire systems of the port street because if you try to wait until every package from the port street builds, we're never going to have a release. At any given time, there's always stuff. Yes. Exactly. And we do have those lists afterwards, but the list of packages that we have would be what sends us the alerts as to whether or not it requires manual interaction to go through and fix the port street or if, okay, this at least passes the smell test, then we'll go through and look at the lists of other ones. Yeah. Exactly. So FreeBSD ports already has a bunch of smell tests like that and checks for automated systems like that. This wasn't necessarily to alert developers that their port is broken because FreeBSD port team was already handling that and does regular builds like that. This is more from our side for a release engineering is, like, we cannot release if these 50 packages are not available. So those would be, again, our critical bellwether packages. If some minor, you know, library package on the side was failing to build, okay, it's nice, but nobody's complaining. It's not considered critical to our use case. So, and we would take requests for new essential packages and things to add to the list. So it's grown over time as more and more people have requested things. Yes. When you say you come across like graphics drivers like Nvidia drivers that happens to drop an older car, do you then have to go up a decision to we want to drop an older car in support in ours or keep it? No. So when I talked about the Nvidia driver in particular, this has happened a few times with the Nvidia driver. The Nvidia driver port is always just the latest driver from Nvidia. But every so often, Nvidia drops and creates a new legacy driver. So they have the 304 driver, the 340 driver, and then the current one right now I think is 390 or something, but that one's still rolling with whatever the latest is. Every so often when they create a new legacy driver, people that had the latest in driver installed will still, when they upgrade, they'll still get the latest driver, but that driver might not be, it might not have the same support as the new legacy driver, and they actually need to roll over to the legacy driver instead. So you actually have to do a quick check to say, okay, usually we can't automatically convert people like that, but we can at least warn people of it ahead of time saying, hey, this driver might not work if you're having any graphics issues, run this one command to replace the latest driver with the new legacy driver. So we've had to do that a few times, but it lets us catch things like that and at least warn people ahead of time. We do include multiple versions of the new driver installed. Yeah, a package repo will have all the versions of the drivers, but you have to actually replace one of the drivers with the other one with your packages, because the upgrade can't do it seamlessly. All right, service management. I already mentioned Open RC a little bit, so this is one of the other big changes that we have been championing and pushing for FreeBSD is that we should use OpenRC as a replacement for the RC.D system in FreeBSD because it is a state aware management of services. You can actually get statuses of all your services rather than the RC.D system where only a handful of the services would actually report whether they're running or not. Most of them just return errors if you ask for status, even though they might be running just fine. Proper dependency handling of services. One of the things about OpenRC was that you can say, okay, yeah, I want to turn on this service at boot, but then the service says inside of it, oh, by the way, I need these other two services. You don't have to manually go read the documentation and figure out, okay, so if I want to turn this one on, I also have to turn this one and this one on. OpenRC is really good about that and says, oh, you turned this one on, but it says it needs these. Those are also available, so it will start them up beforehand so that the one you want does work without having to do a lot of hand holding or without having to do a lot of manual reading and configuring. And then the other thing that we got as a side effect is that OpenRC really is the next generation of RC. It's the same kind of system, same methodology, but it's written as a C binary with shell-like service files, so you just get much faster operations. So the boot times went drastically down and we got a lot of other benefits from switching to OpenRC at that time. And we're actually still pushing towards FreeBSD and trying to get FreeBSD to move over to this. This is one of the things that we have been trying to champion for FreeBSD Current saying, hey, you might want to consider switching to this. It will restart services. OpenRC actually has two different types of service management. The standard Start, Stop, Damon is very similar to FreeBSD as it starts it and if it stops, it stops, but at least you get warnings now of when you check the status. It says, oh, yeah, that service crashed. There's an additional type of supervisor within OpenRC called Supervise Damon where what it will do is if the service specifically says I am supervised, it will launch it, but if it ever crashes, it will automatically restart it, but then it will keep a counter of when was the last time the service was started and how many crashes has it had since it was manually started. So if you just do an RC status to see the status of all your services, you might see something that says, okay, there's the times of all the services and some of them will have a parenthesis with like five inside of it. This has crashed five times and been restarted five times automatically. Gives you an idea that, okay, you might want to go check on that. Yes? Is there a way to disable that functionality? Is there some security? Yes. It's one flag within the service file. It's really easy to switch back and forth. Yeah. And that's why I said it's on a service by service basis. So some of them might be supervised. Some of them might not. It just depends on what you want. All right. One of the other changes that TruOS has, we have a very, very different rules of conduct. I know this is something that came up recently and I was asked to put this in here and I think a lot of people care, but really, we don't care. All we care about is the code. That's what it comes down to. As long as you can behave civilly and send in code, that's all we care about. Other than that, go your own way. That's our rules of conduct. In addition, our contributor policies are a little bit different in that we are completely GitHub based. We do not use SVN. We actually use GitHub for everything. All of our pull requests and reviews and merges are all completely public and anybody can go back and look through them and view them very easily. That's just like most other things like subversion stuff. But with GitHub, it just makes it really, really transparent and easy for anybody to browse it and search that really quickly. It streamlines the submission process considerably. Literally for all you need in order to send in a patch to the TruOS project is a web browser. You can go to our repo. You can find the file, edit the file directly there within your web browser, open a pull request in three clicks and you can be done and send in a patch in literally, you know, ten minutes or less, depending on the size of the patch, obviously. We also have a one week timeout on patches. And by this, what I mean is if nobody has, if the maintainer or reviewer times out after a week, after a pull request has been sitting there and there's been no objections to the patch or whatever, then one of the TruOS developers will review it at the end of that week and just commit it or deny it right there by fiat. No questions asked. We do not have pull requests or patches that sit in limbo for a year or two. Everything is dealt with and handled on a very responsive basis. So that is one of our things that we are very, very passionate about. If you have a change and you send in a change, we will respond to you in a very timely basis. Most of the pull requests, you will get a response or get it merged in within a day or two. That's typically our process. Yeah. And that kind of happens, especially as the projects get bigger. So we put this in place really early with our system on GitHub and we have been very strict about holding to this kind of timeout because we do not want to let PRs back up. We do not want to let issues continue to back up. So, I mean, feature requests and stuff, that is separate than sending a PR. If you have a patch and you send that in, that will be dealt with instantly. Now, just somebody asking, hey, I want this. Why don't you do this for me? Yeah, that might sit for a while, depending on if somebody wants to get around to it. That's different than actually somebody sending in code. Package management updates. I mentioned that we do have base packages in addition to what I call ports packages because it's not just packages. They are packages from the port street. So we have package set up with two repositories, one for base, one for packages so that we can update one or both simultaneously as need be. So the base package repo, for those of you that aren't aware, this will contain the package files for things like installing the FreeBSD kernel, runtime packages, things like send mail, the dash develop, those are the development symbol files for each of the individual packages and all sorts of other ones. So it's basically broken up. I think there's 120 different packages within the base package repo. That's how it breaks down. And then we have the ports packages. The other thing is that PC update manager. Again, FreeBSD doesn't use base packages right now. You can't use the exact same methods that FreeBSD does in order to update your system because the back end is completely different with the base packages. So in PC update manager, what we quickly discovered is that we needed an update script, PC update manager is written completely in shell, but it self-bootstraps itself. And this is really important because it gives us a mechanism whereby when we're doing a release and we have everything staged and ready, if we find an issue actually performing the upgrades on our test systems, we don't have to completely rebuild all of the release packages again and all the ISOs and everything. All we have to do is patch PC update manager because when it runs, it will self-bootstrap itself to the latest version to make sure that you have the patches for that update. So that lets us get a very, very quick turnaround to fix any type of update issues without having to issue completely new package sets, all 60 gigabytes of packages from the ports tree. So we discovered that very early that we needed a mechanism like that just to fix and resolve issues like that on a very timely basis because problems with updates are something that are a killer for distributions and stuff. You can't update properly, then you're going to have a lot of troubles. So that's where we are with TrueOS right now. Do you have any questions on that before I take us to the new stuff? Yes. How well does it operate under Zen? Under Zen. I haven't tried to understand. I actually don't try as much of the virtualization stuff. We use a lot of virtual box and VMware and VHive. Zen, I know some people use it, but I haven't heard them complaining so it might work perfectly fine. I just don't know. I just don't use it. Yeah. What's the status of TrueOS Pico? TrueOS Pico is a project that Chris developed which is pretty much a static image for the Raspberry Pi itself, but he kind of got sidetracked after getting promoted to VP of engineering at IX systems and hasn't had as much time to work on that. So it's still there and what's there works. We haven't gone through and disabled it, but it's still limited to the Raspberry Pi 2. He hasn't created the new images for Raspberry Pi 3 and some of the other boards. Do I talk to him if I have questions on? Yes. Please talk to him if you have questions. Yes. Everything you do is on GitHub and all the other stuff. I think some people may worry, okay, this is a commercial product. What is their secret sauce, binary bits if you don't share or Facebook? No. Something that TrueOS has, we have no private repositories. We have completely public repositories. We don't have any closed source bits that we dump in or whatever. It literally is free VSD just taken to the next level, still completely transparent and open source. Any other questions about TrueOS as is? Yes. IAX systems is the owner slash sponsor of TrueOS. Back in the PCBSD days, Chris started the project by himself and then he was purchased by IAX systems so that it became a part of IAX systems and he was hired to continue working on the project. Effectively, it got folded into IAX systems. IAX systems is officially owning it and sponsoring it and they're the ones that are creating all the build servers and running the tests and many of the IAX systems employees are paid to work on this and there's a lot of development effort put into it. Yes. Is TrueOS used within IAX systems? All over the place. Yes. Other questions? All right. Well, let's go on. Okay. So that's where we are right now with TrueOS or I should say two months ago with TrueOS. So what's going on with TrueOS right now? We just had an announcement a couple days ago about a shift in direction for TrueOS and that's kind of what I want to talk to you here. So TrueOS is changing. We announced a couple days ago that TrueOS is growing into a distribution platform for anybody to easily build their own custom distribution of FreeBSD or TrueOS with just a couple of quick commands. So it is a full-blown, I think Chris is using the term downstream fork of FreeBSD. So that repo there, if you go to the github.com, TrueOS, TrueOS repo, just like FreeBSD has their FreeBSD slash FreeBSD repo, the read me on that repository if you just scroll down to the bottom will give you a long list of changes from FreeBSD, some of which I have listed here. One of them open RC. I've already mentioned that we've been using it for a while and that's one of the differences from FreeBSD at the moment. Package, Poudre and the root NSS certificates are all built into the base operating system itself. You no longer have to worry about package changing versions in the middle of an update because the release cycles are so much faster than FreeBSD. We can stabilize package for a few months at a time and then only roll out updated versions of packages with those release cycles. The root NSS certs because I believe the note Chris put on that in the read me was because not being able to use HTTPS initially is just dumb. I think that's basically what he said. So you get HTTPS support and encryption support out of box. And then Poudre. So one of the things that is specific to this to turn it into a distribution platform is the build system of it itself has now been collapsed down to a single JSON configuration file. We call it a build manifest that you supply to the build and it will build all of the base, all of the ports packages, create the package repositories for you, as well as apply any of your custom install overlays, build overlays, build configuration changes. It's basically the one file to rule them all. And you can literally build your own distribution of FreeBSD. I think it's three commands. You fetch the repo, give it the manifest and then run make, build, world, build kernel, make, build packages, make release. And that does everything. It generates, it signs all your packages, does the whole nine yards. So that's what we are going. So this would help, will help downstream consumers of true OS to very easily customize and build their own appliances with just the individual packages they need but might not be pointing to the true OS package repositories anymore. So they can stabilize and do their own updates on their own schedule instead of being fixed by what we decide to do at the true OS project. It gives the freedom to everybody. But we are going to continue to release and update our own package repositories on the fixed schedules like we always have as well. So again, it's more freedom for all of our users. In addition to that, we are also changing the organization of the project a bit. The desktop side of true OS, which again was kind of minimized a little bit with the change to true OS because we were focusing more on changing the base system, is actually getting split off as a new desktop based distribution of true OS called Project Trident. This is a completely separate project. It is community based and community owned. And it is going to be something completely new as a distribution of true OS. Similarly, GhostBSD is going to become a desktop distribution of true OS rather than following the freeBSD releases as well. And then along with the system, we anticipate that we will have many more new distributions of true OS to announce in the near future based from either corporate products or other user products or community projects as well. And that's literally all I had. So with regards to the split of the project, I am actually taking the lead and running Project Trident as well. So we do have a website that we just put up. But Chris, since me and Chris have kind of historically done the entire thing together, he's going to focus on the base stuff and head up true OS within IAX systems and then I'm going to head up Project Trident within the community. Yes. So Trident and Ghost are both desktop systems? Yes. Why the split? What's the difference between them? GhostBSD has actually been around for quite a while as a distribution of freeBSD specifically focusing on the Matei and XFCE desktops. Yes. Yes. That's Eric Turger there. He runs GhostBSD. Yeah. He created it. So it's kind of an analog to PCBSD. PCBSD was KDE focused. GhostBSD was GTK and Matei and GNOME focused. Although not GNOME anymore. It's Matei and XFCE. So it's just different, similar ideas, but just different ways using different tools and stuff. So GhostBSD, what's your latest release for GhostBSD? 11.1. 11.1 based on freeBSD 11.1. Okay. There you go. Yes. In the back. Sorry. Are you doing true server? What was that? Is true server going to remain as a product? Yes. So one of the things is because we're spinning off the desktop side to Project Trident, what we're doing is we're trying to take the true OS repository and take it much, much closer to freeBSD. Aside from the changes I listed there, I mean, we've always had questions from people on the freeBSD side who didn't want to take changes from true OS because they were worried about getting desktop bits. And it's like, no, no, no. It's like we've been focusing on the underlying systems and no, there's nothing desktop there, but we're formalizing that a lot more. So that true OS will probably move to server focused releases and leave the desktop focused releases to Project Trident. So we've historically had both server and desktop releases for true OS for the last two years, but people still tend to say, oh, that's just a desktop when, no, it's a variation of freeBSD. So we're just kind of formalizing that so that true OS is known as the underlying system. It is a server or you can redistribute it as a desktop. Yes. I'm curious what the relationship between true OS and free NAS are in terms of their code base. How much? No, no, no. The shared development. Free NAS is also an IAX systems project. True NAS is based off of it. Free NAS is based off of freeBSD. And it is not based off of freeBSD releases as much as it is based off of freeBSD stable branches because, once again, releases are too slow, so they follow the stable branches. And there has been a lot of duplication of effort to try and keep that base up to sync by the same token true OS and the other projects trying to, again, keep their base up to sync with freeBSD with whichever branch they're following. We are currently evaluating within IAX systems whether free NAS can move to true OS. And we're doing prototypes. Other than that, we'll wait and see. See what comes of it. Over here. Would it keep developing the Lumina desktop? Yes. So I actually am the author of the Lumina desktop and that's one of the things that we're going to do within Project Trident. So Project Trident is going to continue following the same tact that true OS desktop side has been doing for a while, which is Lumina desktop, that uses the Lumina desktop by default, but then it also emphasizes and tries to create a much more pureBSD system instead of relying on a lot of the Linux subsystems like Pulse Audio and stuff. We're actually going to try and do a lot more of that within Project Trident to keep it pure to freeBSD and help enhance development within the freeBSD community. That's one of our goals. Other questions? Yes, back there. Now you were saying you can fork true OS over. Say I want to do that for my appliance. Make the changes that I need. How it is to then pull your changes from the next release into mine. Very easy. Actually, have you used GitHub all that much before? A little bit. GitHub makes forking and then sending changes back and forth between forks incredibly easy. All right. So you can literally just fork our stuff at a particular tag. We're actually doing very smart tags of the different builds and versions of the source tree on GitHub as well. So you can specify, okay, I want to fork true OS at release tag, whatever it is, blah. It could be an official release or it could be one of the intermediate development releases. It's up to you. Do your builds and then literally on your thing say, okay, now I want to re-merge or re-sync with the upstream fork and do all that and then you just might have to deal with merge conflicts for changes that you have to do with yourself, but it's very, very easy to keep that up to date. That's actually how true OS has been maintaining its fork of free BSD for a long time because we re-sync with the free BSD repositories on a very frequent basis as well. And actually on the true OS, true OS GitHub repository in the very top of the readme is the tag with the latest date that they have synced with free BSD head. So that we keep up to date. So as changes are getting put into free BSD, they will also end up in true OS and then by the same token, we're hoping to help push more stuff from true OS into free BSD as we provide the testing platform for free BSD developers to test and approve changes and stuff. Trying to help make it easier everywhere around. Yeah. Yes? IAIC systems is sponsoring project right there. Actually the first sponsor in helping us get everything spun up and going. But IAIC systems has always looked at it ever since the PCB SD days as really a goodwill gesture and an R and D for a lot of the other mechanisms within IAIC systems because all the products within IAIC systems are based off free BSD. It was very helpful to have a small team on the PCB SD side of things constantly pushing the boundaries and trying new things and developing new technologies. So it was that plus marketing. We go to conferences, we talk about IAIC systems. There's all sorts of benefits like that. I'm sure if you talk to different people at IAIC systems, you'll get different answers from every single one. But that's the one I've always seen and heard. Yes? Is there a plan to unify true OS and the GhostBSD community? No. I don't think there are any plans to unify the communities. I mean, GhostBSD is a separate standalone project. I don't see any need for them to shut down their forums and tell other users to move to true OS. Like coming on their quarter to try them? Yeah. So pretty much every distribution of true OS is that they can do that however they want. They can run their own forums. They can have their own communities. It's up to them. So we don't enforce any kind of give back from our distributions. So is that a good answer? Yeah, that's a good answer. Because, I mean, there's been some talk because of project trident's a little bit more of a special case because it really is the continuation of the true OS desktop. So we'll probably have some overlap on the true OS forums with project trident at least for a while. But I don't know if the plan is to eventually start up a new forum or whatever for project trident. We just haven't worked out those details yet. Other questions? Yes? Maybe it was mentioned that you have an upcoming release date or event for a project trident. Yes. Under that name, we are planning for our first release to come in about two months. So we have scheduled for one more final release of true OS because we've been promising people an 1806 release of true OS itself. For a while now, we're going to stick to that promise. We will release true OS 1806. And then project trident will be releasing its own version probably two months, the first version will probably be two months after 1806 using the new systems and based off of that. One of the other changes with project trident, you know how I mentioned the release schedules for true OS, there was stable and unstable. With project trident, we're planning on only having one release schedule and that is a stable base operating system, the stable version of true OS, but then we're going to have a rolling ports tree packages. So you'll have atomic diffs for end user applications during a release cycle and then we'll only update the actual base OS packages every six months. So that's our plan for trident, again, we'll see how it goes. We're trying to keep it quiet for the first time and make sure that things actually flow smoothly before we firmly commit ourselves to dates, but that's what we're thinking of. Yes. So if you're running to us, I'm not running to get a point to doing something. If I have true OS and then project trident, is it an easy transition? Yes, we actually have planned a full upgrade path directly from true OS to project trident. We actually have within the true OS project right now, we have two different meta packages that we install, one of them is true OS desktop and the other one is true OS server. So obviously if you during the upgrade, if you have true OS server installed, okay, it'll keep you on the true OS repositories and keep going with that. That's an easy transition. We had talked about looking and if the true OS desktop package is there, it'll just immediately upgrade you to project trident, but then there's a few people that are also wanting it's like, okay, if that's there, maybe give people the option to upgrade to trident or upgrade to ghost BSD. So we're looking into possibilities, maybe we'll have some kind of switch down the road, but none of that's been finalized yet. Any other questions? I guess I've clarified a little bit. Yes. If the get company book says more or less a fork. Yes. Chris uses that for that word a lot. I don't like that word. Yes. He's used the term fork there. He uses the term downstream fork quite a bit in conversation with him and stuff. He's trying to make it across that yes, it is different from free BSD, but no, it is not separate from free BSD. We are still very much joined together. We are still sending changes to them on occasion. We are still getting changes from them on periodic that occasion. We try to keep in close with the free BSD community. It's not like we're trying to say, oh, you know, so long we're going to do our own thing. It's not a fork like that. So it's, I guess we just haven't found the right terms to describe it, but yeah, that's basically what it is. It seemed to be like you were hoping to track free BSD. Yes. And again, some of the changes that we've got from free BSD right now were, again, working with free BSD people to get those into free BSD. With OpenRC, for instance, we would love to help free BSD move to OpenRC. Base packages. This is something that a lot of free BSD people have been wanting for a while. It still hasn't been rolled out or implemented yet, but we're just a great test case of it can be done. Here's the fixes and patches we've had to do to get it working. And we're working with them so that free BSD can use package base as well. So we're trying to, even though we've got a bunch of diffs between us and free BSD now, we're actually hoping that we'll get shorter over time. And then maybe again, it'll get longer when we start, you know, working on some other new thing that free BSD might need and we'll work on it and get it up and going and then send that to free BSD again and try to sync it in. Which is, yeah. Hard to describe, but yes, we are very connected to free BSD and we want to stay connected to free BSD. We don't want to just say, you know, so long and, you know, be our own thing. Yes? What's the support model for TrueOS? Are you talking, what type of support are you talking about? I'm assuming so it's a commercial offering, right? Yes and no. It's actually a community offering by a commercial provider. So IX Systems does not actually sell support plans for TrueOS. So it is all still just community support, yeah. But IX, does it sell part of that community as well? Yes. And so a lot of the IX people, like the FreeNAS developers and stuff, they'll often, you know, within the TrueOS community, if people have really advanced ZFS questions, we'll say, hey, go ask on the FreeNAS forums or maybe we'll get a FreeNAS developer over here and answer your questions over here because they go into such more detail on ZFS and the storage side that we might never do. But we have so many pools of experts all over the place, each of them focused on various parts of FreeBSD that we kind of see our, I kind of see TrueOS as kind of like a melting pot of that and the glue to help bring people into FreeBSD via TrueOS and then help them find all the communities and get hooked into everywhere and become part of the community. Other questions? I don't know how much time we've got. I'm just guessing. We have 20 minutes. Oh. Actually, 10 minutes. 10 minutes. We need a minute break. Okay. Yes. I have a question aside from TrueOS. I just want to add to the experiment, or to bring IAIC systems to Europe. Bringing IAIC systems to Europe, you would actually have to talk to Chris about that in management. I am a lowly peon in the IAIC systems infrastructure. Yeah, Chris is actually vice president of engineering, so he's involved in a lot more of those decisions. I'm just one of the engineers. Yes. You mentioned OpenRC, packed space. You're so giving yourself freedom to say we're going to test that and stuff. Yes. Are there things not in TrueOS that you would love to put into it, if you were king for it? There's always ideas getting thrown around. Whether we actually start doing it or not is another matter, but that's the thing. With the computing world, it's always changing. So even though we might not have something in mind right now, who's to say a year from now, something really important doesn't come up. It's like, you know what? That's a really good idea, and we try to do something like that. We really don't know. We're leaving our options open. One of the things with PCBSD and TrueOS, we've always been very, very flexible and very reactive and very dynamic to what's going on in the ecosystem of Linux and BSD and pretty much all open source projects. So we try to keep that flexibility and just leave doors open so that we can start helping other projects and things do that. That's one of the other reasons I wanted to bring up all these differences from free BSD. It's not trying to trumpet TrueOS, but I mean, we're open. We want to talk to people. We want to help other distributions. We want to help NetBSD and OpenBSD. If what we have tried and didn't work is any example, maybe learn from our examples, it may be a six-month release would work great for NetBSD or DragonflyBSD. Maybe, you know, just learn from us. We're here to help everybody whether you use our stuff or not. That was kind of actually the whole reason I put this talk together. It's like, okay, we've done a lot over the last several years. Let's just tell people what we've done, what we've worked with, what didn't work, and this is what we've found that seems to work really, really well. Six months release schedule is probably easier to save than to do. Yeah. That would be the easiest one to adapt in other ones. Of course, individual technologies are on a, you know, case-by-case basis always. Sometimes in a community, open source community, people might get paid new releases. Sometimes it's hard to get people to push through. And that's one of the reasons why we set up the distribution system for the NeutroS repo, the way we did is we actually have the automation framework for doing it via Jenkins, also baked into the repo. So we actually have a Jenkins setup file directly in that repo as well that anybody can take and distribute to distribute their own Jenkins instance to automate the creation of all the packages and stuff for them. So we're trying to do that to help, you know, communities, help people that want to start a distribution get up and running with as little effort as possible rather than, again, expecting you to be a guru and know exactly which bits you need to flip here and there within the source trees in order to build a custom distribution. Yes. I did not research this prior. I did notice that the mostly VBSD and back extension 2.0 like this one, you can see more of our FreeM네요 and graphic, Chao for my Well, from what I understand, they're actually looking at possibly giving us CUDA and stuff, but mainly because we were still behind from Linux, and most of that stuff was using Linux frameworks. Now that the DRM work has gotten in and they can use some of those, they're more open to turning on those bits in the proprietary NVIDIA drivers so that we can get CUDA support and stuff, because the underlying systems are there for them now. Yeah. But we still need to wait for them. It's not necessarily in our hands. So if you want to talk to NVIDIA and keep asking them for it, by all means, please do. Open CL support and CUDA support would be fantastic in the NVIDIA drivers. The driver has all the things that the place that they doesn't provide, they need to have libraries to help them to actually use like a power. They're not willing to go to do that. But I've been able to compile Linux binaries that were using the two libraries that run the final three-disk. And they'll use the two that's in the driver, okay? So they're actually a Linux binary and they can use their watchers. Okay. Any last questions? All right. Thank you very much. If you have any further questions, I'll be down here or at the IAC systems booth if you want to talk anymore. Thank you. Please leave a comment exporting this file to output. Okay. Thanks for recording me. Bye, yeah. Bye bye. Thank you and thank you very much.
 Alright, so before we get started, I just have a few quick questions that I always like  to ask people before I ever give a talk like this.  First one being, since we're at a BSD conference, everybody who uses open BSD, raise your hand.  Everybody who uses net BSD, raise your hand.  What?  Nobody?  Dragonfly BSD.  And FreeBSD.  Other.  You.  Okay.  So, I just generally like to do lots of little quick polls for people right before I talk.  Usually, I do give these kinds of talks at Linux conferences where nobody's ever heard  of BSD, so I have to kind of explain what it is.  So I always have to explain, okay, what FreeBSD is and how it's descended.  That's fine.  Since we're at a BSD conference, though, I can be a little more specific.  So I assume most of you have heard about TrueOS before.  Am I correct in that?  Yes?  Yes?  Okay.  Other hands.  How many of you have not heard about TrueOS?  Good.  I don't need to explain myself then.  Oh, wait a minute.  Do you?  Okay.  You're good?  Okay.  So I don't need to go into too much detail.  I mean, I'll give you a little bit of detail in here, but I don't have to go into gory  details or whatever if you're already familiar with it.  How many of you have actually used TrueOS at one point?  All right.  How many of you used TrueOS right now at the present time?  Okay.  How many of you ever used PCBSD?  A few of you?  Okay, good.  That gives me a rough ballpark of what kind of audience we've gotten.  Now, how many of you are interested in TrueOS but haven't heard any of the recent developments?  Okay.  Like the stuff that happened, what was it yesterday?  Two days ago?  Yeah, the blog post that came out a couple days ago.  Are any of you familiar with that already?  Yes?  No?  Okay.  Well, I do go into a little bit more details on that at the end of this talk because this  is kind of what this talk was going into is why what was announced is actually what's  going where we're going going forward.  So this will lead into that and explain the background of the project and why we're going  where we've been heading and just haven't told people until now.  That's always fun.  And just for my own benefit, completely unrelated to that stuff, how many of you used the Lumina  desktop?  One of you?  Oh, a few of you.  You mean regularly or how many of you used it?  How many of you used it within the last month?  Okay.  A lot more of you.  Good.  Now, are you using, those of you that are using it, are you using the latest release  version on FreeBSD, which I think is 1.4.0?  Or are you tracking the newer releases from the source repo, which I think is 1.4.3 at  the moment?  FreeBSD packages?  OpenBSD packages?  Yeah.  Okay.  That's kind of what I expected.  What version was in the 1.8.0.3 TrueOS?  1.8.0.3 TrueOS.  Yeah, I think that one's a little older.  That's 1.4.1, I think.  All right.  Sorry, I've got two minutes.  I'm trying to kill time.  Anyone know any jokes?  I try to be a comedian, but everybody just laughs at me.  I don't get you every time.  Yeah, almost there.  Does anybody know how the recording system works?  I heard it was supposed to be recorded, but do I have to stand right here?  I've got the mic.  Oh, this one.  So I need to stand over here so people can see the slides.  Over there?  Okay.  They're not recorded.  Okay.  So do you want me to stand over there out of the corner or something?  Like over here.  Yeah, that's what I was going to say.  So if I'm in the corner, hopefully I'm not covering the slide.  Yeah, that's true.  I should probably post them somewhere then, shouldn't I?  Yeah.  Okay, I'll try and stand here.  I tend to pace, but I will try to remain fixed.  And that took the rest of the time.  So, all right, welcome to my talk.  This is the TrueOS difference.  For those of you that aren't familiar with me, I'm Ken Moore.  I work on the TrueOS project.  I was part of the PCBSD project back in the day.  I was one of the founding members of TrueOS when we made the name switch.  And here to talk to you a little bit about it, shore up some things that people might  be confused about, you know, enlighten people that weren't aware of things.  So this is just a quick, very rough outline of what we're just going to go over today.  I'm going to try and do a very quick history of TrueOS just to give you all the context  of why we do things differently than FreeBSD and why we've decided to focus on these differences.  And we'll go into changes from FreeBSD because TrueOS is based off of FreeBSD itself, but  we change a number of things.  And so I'll go into some of those.  And then I want to go into some of the next steps, stuff that was mentioned in the release  announcement a couple days ago, and go into, with all this context, I think a lot of that  will start to make a lot more sense for why we're changing directions.  So first off, PCBSD.  Number of you said you were familiar with it, had even used it.  So I hopefully don't need to go into too much detail on this, but it was started in 2005  by Chris Moore, who is my older brother, it's not me.  And he started in 2005 as a desktop focused version of FreeBSD release, and the original  version of PCBSD was based off of FreeBSD 6.0.  He gradually started creating and adding utilities to PCBSD at the time, specifically for shoring  up some of the weaknesses.  PCBSD was based off of KDE 3.  So he created a new network manager in QT 3 to go along with KDE because the KDE network  manager wasn't working properly with FreeBSD, things like that.  So eventually he created some utilities such as PCSys install, which is a scriptable installer  for FreeBSD rather than the text installer.  PCNetManager is the network manager I mentioned a moment ago, and there's a number of other  ones.  All of the utilities that he created for PCBSD were submitted back to FreeBSD as ports.  I believe most of them appeared in the sysutils category, and they were all PCBSD dash something  in the ports tree.  Gradually he started delving into adding and customizing the FreeBSD ports themselves on  a regular basis because he discovered that many of the ports, the build options for the  ports were not designed for desktops, like they had all the graphical stuff turned off,  and then when you run it from the desktop, you wonder why things don't work properly.  So he had to start building his own ports tree and building his own packages with different  flags turned on just so it would integrate properly.  So he started maintaining a fork of the FreeBSD ports tree.  I joined on the team a little bit later after that, and PCBSD kept going till the 10 series,  FreeBSD 10.  And then in the end of 2015, very beginning of 2016, we decided to make the plunge.  We had always been based off of FreeBSD releases for PCBSD.  But then we started, it's like, you know what?  Every time FreeBSD release comes out, we would determine that it was already at least a year  or two obsolete for modern laptops.  It would never work with stuff that had come out within the previous year or two.  So since we were based on releases, even though something was brand new for us to the rest  of the community and the consumers, it felt like, oh, that's old news.  It doesn't work on anything new.  So we started rolling builds of PCBSD using FreeBSD current instead of FreeBSD release  branch.  So I think it was December of 2015.  So I put the end of 2015 there.  But by December of 2015, we actually had a rolling build of FreeBSD current at the time,  publishing pre-release images of FreeBSD 11.0 from the current tree.  As part of this move to current, though, we also started using some new systems in FreeBSD  which were planned and scheduled by the FreeBSD team for release in 11.0, namely package base.  So this is something that FreeBSD still doesn't have in the 11.0 series, and they're still  talking about whether it's going to get put into FreeBSD 12 or not.  But PCBSD or TrueOS has been using package base for almost two years now.  We've actually been using it and testing it and committing fixes to it right back to FreeBSD.  At the same time, though, Joe Maloney came on board at the TrueOS project, and he was  very, very interested in this new system called OpenRC to help replace some of the service  management systems on FreeBSD.  Chris and I had been looking at a lot of alternative service management systems like  NoSH, LaunchD.  There was one or two other ones as well.  We've been evaluating them for a while, trying to find something to help make things boot  up faster and easier to manage.  So when Joe Maloney came by and he's like, yeah, I actually have a build of OpenRC on  FreeBSD over here, we were very interested and we started running some builds with it  and testing it and toying with it for a while.  So in 2016, early 2016, after we had been rolling these current builds of FreeBSD for  a few months, we decided that, okay, so much has actually changed underneath the hood from  these rolling release builds to the release builds of PCBSD that the upgrade path was already  completely shattered and broken.  There was no way for somebody to go from a release of PCBSD, I think 10.3 or 10.2, was  the last release of PCBSD.  And then we had these rolling release images, but there was no seamless upgrade path.  It was a really complicated mix of hacks and manual commands and it got ugly really, really  fast trying to move to these new systems of package base and OpenRC.  So we decided that at that time, okay, so much has changed, we've ripped out so much  of the old system that was there for PCBSD and we've put in so many new subsystems,  we didn't really feel right calling it the same thing anymore because we were also focusing  from the true OS perspective on different systems.  We weren't just doing desktop stuff anymore.  We were now talking about configuring FreeBSD.  We were tinkering with the FreeBSD underlying system itself.  We were no longer just being a desktop built on FreeBSD, which was the point of PCBSD at  the time.  So we announced that the PCBSD project was ending and that the true OS project was the  next evolution of it to take its place, much like a phoenix rising from its own ashes.  So that was the beginning of the true OS project in early 2016 and it really had a very different  focus.  First step is that it was consumer focused instead of desktop focused.  So we weren't just doing a build of FreeBSD and then slapping a desktop on top like KDE4  was what we were using at the end of the PCBSD days.  We were no longer just a desktop distribution.  We were literally a customized version of FreeBSD, implementing a lot of changes in FreeBSD  that FreeBSD, people who are following FreeBSD releases wouldn't have for another year or  two depending on when the next scheduled release was because we were being based off the current  branch of FreeBSD, not the release branch of FreeBSD.  So our timetables were greatly accelerated from standard distributions of FreeBSD.  We basically moved from a downstream consumer of FreeBSD releases just using whatever FreeBSD  gave us and actually moved into an active tester and contributor back to FreeBSD because  we were providing FreeBSD developers users and people that were testing their changes  very quickly after they were committed to FreeBSD head and providing active response  right back to them so that they could get things, issues worked out and resolved well  before the FreeBSD release process ever got kicked off.  One of the other ways that we would do this is actually emerging FreeBSD developer branches  into base ahead of time. If they got bogged down in some kind of issue either in fabricator  or something, we would actually merge those branches and work with that developer to get  their changes put into base ahead of time so that they can prove to the FreeBSD project,  yes, it looks like it's a drastic change, but don't worry, it still does work very well.  We have live builds, see if it works fine.  So we would do stuff like that and we were very instrumental, I won't say exactly very  instrumental, but we helped with that considerably with regarding the new graphic stacks for  FreeBSD involving the newer Intel drivers and DRM next stuff. We were pulling those  in and using that and providing feedback on that very, very early.  So okay, that's the end of the history of TruOS. That kind of takes you from PCBSD up  to TruOS at the current time. Do you have any questions on history before I go into  other additional differences from FreeBSD? Just showing how we kind of move from a desktop  distribution of FreeBSD to basically a customized version of FreeBSD current in the back.  What do you say you couldn't really upgrade from rolling release? Does that mean every  time you wanted to upgrade you'd have to wipe and retake?  No, no, no. So the problem was switching trains, if you will. We couldn't go from the stable  version to the rolling release version. Once you were on the rolling release version, you  could upgrade and stay on that fine, but there was a hard break between the two and we couldn't  find an easy and automated way of automating that. So that was a very clear logical break  between the PCBSD days and the TruOS days as we can point to that because there really  was no easy bridge.  That's your watershed.  Yeah. It was a very clear defining moment for us. Yes?  It sounds like you're pushing stuff a lot faster than FreeBSD, you're pushing more  stuff in quicker. Do you have any special methodologies to make sure that it wasn't breaking stuff?  You and that testing?  I'll get into that in just a second. Yes. So, okay, yeah, that's just the general history.  Let's go into a few more of the differences now of what's different now in TruOS compared  to FreeBSD because I've said FreeBSD current many times. Obviously, there's differences  there between FreeBSD current and FreeBSD release. That's a given. But what does TruOS  add to FreeBSD current and what do we do differently?  First step, release engineering. Obviously, since we're based off of current, we're no  longer following FreeBSD's release schedule. So we had to start providing as a project  our own release engineering, our own release schedule. So we've tried many, many different  types of schedules for releases among the PCBSD and TruOS days from weekly rolling release  images to monthly images to mixtures of long-term support releases. And what we settled down  on is actually one that works really, really well for us right now. And that is a six-month  release, which we actually got the idea from OpenBSD. For any of you OpenBSD guys here,  thank you. It was a great idea. So that every six months, you get a stable release. That's  what we call it on TruOS. We have two branches. We have stable and we have unstable. So stable  is a six-month release. There are no changes to base or ports in that time unless there  are like major security issues. That's actually why we issued the 1803 release of TruOS halfway  through our six-month cycle in response to Spectre and Meltdown and stuff like that. It's  significant enough we needed to push out another release image ahead of time. This, the reason  we had something like this was this was perfect for derivative products or appliances. We  had a lot of people that wanted to use TruOS either on their servers or build their own  little appliance off of it. But if you're having weekly updates to it, that's very,  very disruptive to end users, specifically enterprise users that expect it to be like  a static appliance. They don't want it to change. So why does it keep trying to automatically  change things? So stable releases were perfect for that because six months is a long enough  period of time that it's still easy to support it for us because we're a much smaller team  than FreeBSD. It gives us a smaller window. It's like, okay, yes, we will support that  stable version for six months. And then it's also long enough for the end user because  it's like, okay, once I install it, I don't have to worry about it for six months.  Unstable branch of TruOS is much more of our rolling release branch. So this is where  we released much, much more faster. We would do it sometimes once a week. We tried to shoot  for once a month, but we weren't necessarily on a fixed schedule. So we told people it  could be anywhere from every week to every month for a new image of unstable. But what  was unique about unstable was that it was the combination of unstable base and unstable  ports. So if you wanted the new applications and stuff, we kept telling people you have  to go to unstable. That's where we do all the new builds and stuff like that. But the  unintended consequence of that was that you were also getting all the new base bits from  FreeBSD current at the time. So both of them were rolling in sync at all times. All right.  Any questions about release engineering before I move on? So this is what TruOS is using  right now. We still have this, this is our schedule and this is our release engineering.  As part of our release engineering process, we have quality assurance processes. We actually  have fully automated build systems running all the time. And as part of that, we actually  have a bunch of QA procedures built into it as well. So we try to catch things when building  the full ports tree, for instance, we have a list of what we call essential packages  to basically alert us if one of our automated builds, one of these packages fails to build.  It's like, okay, something's going on in the ports tree right now. When all the flavors  for Python got put in, needless to say, we were getting lots of alerts from our build  system because Python 2 and Python 3 were some of our critical ports and things were  no longer failing to build, were failing to build for quite a while. So we have things  like Python clang. Because we do have the desktop side of TruOS, we add things like  Firefox into there and a few of the other browsers, Chromium. So again, if one of those  doesn't build, we consider that a bad ports tree and then we have to work on the ports  tree and then trigger another build until we can get a good ports tree, a good build  before we would consider releasing it. By the same token, we also check things from  base. So bootability with the latest FreeBSD base, we would check the bootloader. We would  check all the base packages and make sure that we could update between one set of base  packages to another set of base packages. Since it was still highly experimental from FreeBSD  itself, we did a lot of checks there. Plus, we did a lot of manual checks. So we would  always install many times, either into virtual box instances, onto laptops, onto desktops.  We would try to manually install and test these images in several places before we would  issue a new set of updates as well so that we could actually get the hands-on test. That's  where we would find out, for instance, if, oh, yeah, the driver is there, like, for instance,  the NVIDIA driver. It's there, it built, but, oh, wait, NVIDIA added another version of  their driver and the latest driver now drops support for all these cards, so we need to  try and detect and fall back to, you know, older versions of the NVIDIA driver for particular  systems and, you know, things to watch out for. That's where, that's the phase where  we would have noticed things like that because we were actually running it on physical hardware  and we ran into some of those things. Make sure that networking works in various types  of situations, check that removable devices are working, things like that.  Yeah. The automated checks is mainly just for builds. Does it compile? Do we get a package  out of it? Using, like, the new versions of Clang and things like that, that was not actually  running it. Running it would be part of the manual test where we would actually physically  install and run a whole lot of things. Yeah. Mainly because we tried to pick certain packages  as, like, bellwether packages for entire systems of the port street because if you try to wait  until every package from the port street builds, we're never going to have a release. At any  given time, there's always stuff. Yes. Exactly. And we do have those lists afterwards, but  the list of packages that we have would be what sends us the alerts as to whether or  not it requires manual interaction to go through and fix the port street or if, okay, this  at least passes the smell test, then we'll go through and look at the lists of other  ones. Yeah. Exactly. So FreeBSD ports already has a bunch of smell tests like that and checks  for automated systems like that. This wasn't necessarily to alert developers that their  port is broken because FreeBSD port team was already handling that and does regular builds  like that. This is more from our side for a release engineering is, like, we cannot release  if these 50 packages are not available. So those would be, again, our critical bellwether  packages. If some minor, you know, library package on the side was failing to build,  okay, it's nice, but nobody's complaining. It's not considered critical to our use case.  So, and we would take requests for new essential packages and things to add to the list. So  it's grown over time as more and more people have requested things. Yes.  When you say you come across like graphics drivers like Nvidia drivers that happens to  drop an older car, do you then have to go up a decision to we want to drop an older car  in support in ours or keep it? No. So when I talked about the Nvidia driver in particular,  this has happened a few times with the Nvidia driver. The Nvidia driver port is always just  the latest driver from Nvidia. But every so often, Nvidia drops and creates a new legacy  driver. So they have the 304 driver, the 340 driver, and then the current one right now  I think is 390 or something, but that one's still rolling with whatever the latest is.  Every so often when they create a new legacy driver, people that had the latest in driver  installed will still, when they upgrade, they'll still get the latest driver, but that driver  might not be, it might not have the same support as the new legacy driver, and they actually  need to roll over to the legacy driver instead. So you actually have to do a quick check to  say, okay, usually we can't automatically convert people like that, but we can at least  warn people of it ahead of time saying, hey, this driver might not work if you're having  any graphics issues, run this one command to replace the latest driver with the new legacy  driver. So we've had to do that a few times, but it lets us catch things like that and  at least warn people ahead of time. We do include multiple versions of the new driver  installed. Yeah, a package repo will have all the versions of the drivers, but you have  to actually replace one of the drivers with the other one with your packages, because  the upgrade can't do it seamlessly. All right, service management. I already mentioned Open  RC a little bit, so this is one of the other big changes that we have been championing  and pushing for FreeBSD is that we should use OpenRC as a replacement for the RC.D system  in FreeBSD because it is a state aware management of services. You can actually get statuses  of all your services rather than the RC.D system where only a handful of the services  would actually report whether they're running or not. Most of them just return errors if  you ask for status, even though they might be running just fine. Proper dependency handling  of services. One of the things about OpenRC was that you can say, okay, yeah, I want to  turn on this service at boot, but then the service says inside of it, oh, by the way,  I need these other two services. You don't have to manually go read the documentation  and figure out, okay, so if I want to turn this one on, I also have to turn this one  and this one on. OpenRC is really good about that and says, oh, you turned this one on,  but it says it needs these. Those are also available, so it will start them up beforehand  so that the one you want does work without having to do a lot of hand holding or without  having to do a lot of manual reading and configuring. And then the other thing that we got as a side  effect is that OpenRC really is the next generation of RC. It's the same kind of system, same  methodology, but it's written as a C binary with shell-like service files, so you just  get much faster operations. So the boot times went drastically down and we got a lot of  other benefits from switching to OpenRC at that time. And we're actually still pushing  towards FreeBSD and trying to get FreeBSD to move over to this. This is one of the things  that we have been trying to champion for FreeBSD Current saying, hey, you might want to consider  switching to this. It will restart services. OpenRC actually has two different types of  service management. The standard Start, Stop, Damon is very similar to FreeBSD as it starts  it and if it stops, it stops, but at least you get warnings now of when you check the  status. It says, oh, yeah, that service crashed. There's an additional type of supervisor within  OpenRC called Supervise Damon where what it will do is if the service specifically says  I am supervised, it will launch it, but if it ever crashes, it will automatically restart  it, but then it will keep a counter of when was the last time the service was started  and how many crashes has it had since it was manually started. So if you just do an RC  status to see the status of all your services, you might see something that says, okay, there's  the times of all the services and some of them will have a parenthesis with like five  inside of it. This has crashed five times and been restarted five times automatically.  Gives you an idea that, okay, you might want to go check on that. Yes?  Is there a way to disable that functionality? Is there some security?  Yes. It's one flag within the service file. It's really easy to switch back and forth.  Yeah. And that's why I said it's on a service by service basis. So some of them might be  supervised. Some of them might not. It just depends on what you want. All right. One  of the other changes that TruOS has, we have a very, very different rules of conduct. I  know this is something that came up recently and I was asked to put this in here and I  think a lot of people care, but really, we don't care. All we care about is the code.  That's what it comes down to. As long as you can behave civilly and send in code, that's  all we care about. Other than that, go your own way. That's our rules of conduct.  In addition, our contributor policies are a little bit different in that we are completely  GitHub based. We do not use SVN. We actually use GitHub for everything. All of our pull  requests and reviews and merges are all completely public and anybody can go back and look through  them and view them very easily. That's just like most other things like subversion stuff.  But with GitHub, it just makes it really, really transparent and easy for anybody to  browse it and search that really quickly. It streamlines the submission process considerably.  Literally for all you need in order to send in a patch to the TruOS project is a web browser.  You can go to our repo. You can find the file, edit the file directly there within your web  browser, open a pull request in three clicks and you can be done and send in a patch in  literally, you know, ten minutes or less, depending on the size of the patch, obviously.  We also have a one week timeout on patches. And by this, what I mean is if nobody has,  if the maintainer or reviewer times out after a week, after a pull request has been sitting  there and there's been no objections to the patch or whatever, then one of the TruOS developers  will review it at the end of that week and just commit it or deny it right there by fiat.  No questions asked. We do not have pull requests or patches that sit in limbo for a year or  two. Everything is dealt with and handled on a very responsive basis. So that is one  of our things that we are very, very passionate about. If you have a change and you send in  a change, we will respond to you in a very timely basis. Most of the pull requests, you  will get a response or get it merged in within a day or two. That's typically our process.  Yeah. And that kind of happens, especially as the projects get bigger. So we put this  in place really early with our system on GitHub and we have been very strict about holding  to this kind of timeout because we do not want to let PRs back up. We do not want to  let issues continue to back up. So, I mean, feature requests and stuff, that is separate  than sending a PR. If you have a patch and you send that in, that will be dealt with  instantly. Now, just somebody asking, hey, I want this. Why don't you do this for me?  Yeah, that might sit for a while, depending on if somebody wants to get around to it.  That's different than actually somebody sending in code.  Package management updates. I mentioned that we do have base packages in addition to what  I call ports packages because it's not just packages. They are packages from the port  street. So we have package set up with two repositories, one for base, one for packages  so that we can update one or both simultaneously as need be. So the base package repo, for  those of you that aren't aware, this will contain the package files for things like  installing the FreeBSD kernel, runtime packages, things like send mail, the dash develop, those  are the development symbol files for each of the individual packages and all sorts of  other ones. So it's basically broken up. I think there's 120 different packages within  the base package repo. That's how it breaks down. And then we have the ports packages.  The other thing is that PC update manager. Again, FreeBSD doesn't use base packages  right now. You can't use the exact same methods that FreeBSD does in order to update your  system because the back end is completely different with the base packages. So in PC  update manager, what we quickly discovered is that we needed an update script, PC update  manager is written completely in shell, but it self-bootstraps itself. And this is really  important because it gives us a mechanism whereby when we're doing a release and we  have everything staged and ready, if we find an issue actually performing the upgrades  on our test systems, we don't have to completely rebuild all of the release packages again  and all the ISOs and everything. All we have to do is patch PC update manager because when  it runs, it will self-bootstrap itself to the latest version to make sure that you have  the patches for that update. So that lets us get a very, very quick turnaround to fix  any type of update issues without having to issue completely new package sets, all 60  gigabytes of packages from the ports tree. So we discovered that very early that we  needed a mechanism like that just to fix and resolve issues like that on a very timely  basis because problems with updates are something that are a killer for distributions and stuff.  You can't update properly, then you're going to have a lot of troubles. So that's where  we are with TrueOS right now. Do you have any questions on that before I take us to  the new stuff? Yes. How well does it operate under Zen?  Under Zen. I haven't tried to understand. I actually don't try as much of the virtualization  stuff. We use a lot of virtual box and VMware and VHive. Zen, I know some people use it,  but I haven't heard them complaining so it might work perfectly fine. I just don't know.  I just don't use it. Yeah.  What's the status of TrueOS Pico? TrueOS Pico is a project that Chris developed  which is pretty much a static image for the Raspberry Pi itself, but he kind of got sidetracked  after getting promoted to VP of engineering at IX systems and hasn't had as much time  to work on that. So it's still there and what's there works. We haven't gone through and disabled  it, but it's still limited to the Raspberry Pi 2. He hasn't created the new images for  Raspberry Pi 3 and some of the other boards.  Do I talk to him if I have questions on? Yes. Please talk to him if you have questions.  Yes.  Everything you do is on GitHub and all the other stuff. I think some people may worry,  okay, this is a commercial product. What is their secret sauce, binary bits if you don't  share or Facebook? No.  Something that TrueOS has, we have no private repositories. We have completely public repositories.  We don't have any closed source bits that we dump in or whatever. It literally is free  VSD just taken to the next level, still completely transparent and open source. Any other questions  about TrueOS as is? Yes.  IAX systems is the owner slash sponsor of TrueOS. Back in the PCBSD days, Chris started  the project by himself and then he was purchased by IAX systems so that it became a part of  IAX systems and he was hired to continue working on the project. Effectively, it got folded  into IAX systems.  IAX systems is officially owning it and sponsoring it and they're the ones that are creating all  the build servers and running the tests and many of the IAX systems employees are paid  to work on this and there's a lot of development effort put into it. Yes.  Is TrueOS used within IAX systems?  All over the place. Yes.  Other questions?  All right. Well, let's go on. Okay. So that's where we are right now with TrueOS or I should  say two months ago with TrueOS. So what's going on with TrueOS right now? We just had  an announcement a couple days ago about a shift in direction for TrueOS and that's  kind of what I want to talk to you here.  So TrueOS is changing. We announced a couple days ago that TrueOS is growing into a distribution  platform for anybody to easily build their own custom distribution of FreeBSD or TrueOS  with just a couple of quick commands. So it is a full-blown, I think Chris is using  the term downstream fork of FreeBSD. So that repo there, if you go to the github.com, TrueOS,  TrueOS repo, just like FreeBSD has their FreeBSD slash FreeBSD repo, the read me on that  repository if you just scroll down to the bottom will give you a long list of changes  from FreeBSD, some of which I have listed here. One of them open RC. I've already mentioned  that we've been using it for a while and that's one of the differences from FreeBSD  at the moment. Package, Poudre and the root NSS certificates are all built into the base  operating system itself. You no longer have to worry about package changing versions in  the middle of an update because the release cycles are so much faster than FreeBSD. We  can stabilize package for a few months at a time and then only roll out updated versions  of packages with those release cycles. The root NSS certs because I believe the note Chris  put on that in the read me was because not being able to use HTTPS initially is just  dumb. I think that's basically what he said. So you get HTTPS support and encryption support  out of box. And then Poudre. So one of the things that is specific to this to turn it  into a distribution platform is the build system of it itself has now been collapsed  down to a single JSON configuration file. We call it a build manifest that you supply  to the build and it will build all of the base, all of the ports packages, create the  package repositories for you, as well as apply any of your custom install overlays, build  overlays, build configuration changes. It's basically the one file to rule them all. And  you can literally build your own distribution of FreeBSD. I think it's three commands. You  fetch the repo, give it the manifest and then run make, build, world, build kernel, make,  build packages, make release. And that does everything. It generates, it signs all your  packages, does the whole nine yards. So that's what we are going. So this would help, will  help downstream consumers of true OS to very easily customize and build their own appliances  with just the individual packages they need but might not be pointing to the true OS package  repositories anymore. So they can stabilize and do their own updates on their own schedule  instead of being fixed by what we decide to do at the true OS project. It gives the freedom  to everybody. But we are going to continue to release and update our own package repositories  on the fixed schedules like we always have as well. So again, it's more freedom for all  of our users. In addition to that, we are also changing the organization of the project  a bit. The desktop side of true OS, which again was kind of minimized a little bit with the  change to true OS because we were focusing more on changing the base system, is actually  getting split off as a new desktop based distribution of true OS called Project Trident. This is  a completely separate project. It is community based and community owned. And it is going  to be something completely new as a distribution of true OS. Similarly, GhostBSD is going to  become a desktop distribution of true OS rather than following the freeBSD releases as well.  And then along with the system, we anticipate that we will have many more new distributions  of true OS to announce in the near future based from either corporate products or other  user products or community projects as well. And that's literally all I had. So with regards  to the split of the project, I am actually taking the lead and running Project Trident  as well. So we do have a website that we just put up. But Chris, since me and Chris have  kind of historically done the entire thing together, he's going to focus on the base  stuff and head up true OS within IAX systems and then I'm going to head up Project Trident  within the community. Yes.  So Trident and Ghost are both desktop systems?  Yes.  Why the split? What's the difference between them?  GhostBSD has actually been around for quite a while as a distribution of freeBSD specifically  focusing on the Matei and XFCE desktops.  Yes.  Yes. That's Eric Turger there. He runs GhostBSD.  Yeah. He created it. So it's kind of an analog to PCBSD. PCBSD was KDE focused. GhostBSD  was GTK and Matei and GNOME focused. Although not GNOME anymore. It's Matei and XFCE. So  it's just different, similar ideas, but just different ways using different tools and stuff.  So GhostBSD, what's your latest release for GhostBSD?  11.1.  11.1 based on freeBSD 11.1. Okay. There you go.  Yes. In the back. Sorry.  Are you doing true server?  What was that?  Is true server going to remain as a product?  Yes. So one of the things is because we're spinning off the desktop side to Project Trident,  what we're doing is we're trying to take the true OS repository and take it much, much closer  to freeBSD. Aside from the changes I listed there, I mean, we've always had questions  from people on the freeBSD side who didn't want to take changes from true OS because  they were worried about getting desktop bits. And it's like, no, no, no. It's like we've  been focusing on the underlying systems and no, there's nothing desktop there, but we're  formalizing that a lot more. So that true OS will probably move to server focused releases  and leave the desktop focused releases to Project Trident. So we've historically had  both server and desktop releases for true OS for the last two years, but people still  tend to say, oh, that's just a desktop when, no, it's a variation of freeBSD. So we're  just kind of formalizing that so that true OS is known as the underlying system. It is  a server or you can redistribute it as a desktop.  Yes.  I'm curious what the relationship between true OS and free NAS are in terms of their  code base. How much?  No, no, no.  The shared development.  Free NAS is also an IAX systems project. True NAS is based off of it. Free NAS is based  off of freeBSD. And it is not based off of freeBSD releases as much as it is based off  of freeBSD stable branches because, once again, releases are too slow, so they follow the  stable branches. And there has been a lot of duplication of effort to try and keep that  base up to sync by the same token true OS and the other projects trying to, again, keep  their base up to sync with freeBSD with whichever branch they're following. We are currently  evaluating within IAX systems whether free NAS can move to true OS. And we're doing  prototypes. Other than that, we'll wait and see. See what comes of it.  Over here.  Would it keep developing the Lumina desktop?  Yes. So I actually am the author of the Lumina desktop and that's one of the things that  we're going to do within Project Trident. So Project Trident is going to continue following  the same tact that true OS desktop side has been doing for a while, which is Lumina desktop,  that uses the Lumina desktop by default, but then it also emphasizes and tries to create  a much more pureBSD system instead of relying on a lot of the Linux subsystems like Pulse  Audio and stuff. We're actually going to try and do a lot more of that within Project  Trident to keep it pure to freeBSD and help enhance development within the freeBSD community.  That's one of our goals.  Other questions? Yes, back there.  Now you were saying you can fork true OS over. Say I want to do that for my appliance.  Make the changes that I need. How it is to then pull your changes from the next release  into mine.  Very easy. Actually, have you used GitHub all that much before? A little bit. GitHub  makes forking and then sending changes back and forth between forks incredibly easy.  All right. So you can literally just fork our stuff at a particular tag. We're actually  doing very smart tags of the different builds and versions of the source tree on GitHub  as well. So you can specify, okay, I want to fork true OS at release tag, whatever it  is, blah. It could be an official release or it could be one of the intermediate development  releases. It's up to you. Do your builds and then literally on your thing say, okay, now  I want to re-merge or re-sync with the upstream fork and do all that and then you just might  have to deal with merge conflicts for changes that you have to do with yourself, but it's  very, very easy to keep that up to date. That's actually how true OS has been maintaining  its fork of free BSD for a long time because we re-sync with the free BSD repositories on  a very frequent basis as well. And actually on the true OS, true OS GitHub repository  in the very top of the readme is the tag with the latest date that they have synced with  free BSD head. So that we keep up to date. So as changes are getting put into free BSD,  they will also end up in true OS and then by the same token, we're hoping to help push  more stuff from true OS into free BSD as we provide the testing platform for free BSD  developers to test and approve changes and stuff. Trying to help make it easier everywhere  around. Yeah. Yes?  IAIC systems is sponsoring project right there. Actually the first sponsor in helping us get  everything spun up and going. But IAIC systems has always looked at it ever since the PCB  SD days as really a goodwill gesture and an R and D for a lot of the other mechanisms  within IAIC systems because all the products within IAIC systems are based off free BSD.  It was very helpful to have a small team on the PCB SD side of things constantly pushing  the boundaries and trying new things and developing new technologies. So it was that plus marketing.  We go to conferences, we talk about IAIC systems. There's all sorts of benefits like that. I'm  sure if you talk to different people at IAIC systems, you'll get different answers from  every single one. But that's the one I've always seen and heard. Yes?  Is there a plan to unify true OS and the GhostBSD community?  No. I don't think there are any plans to unify the communities. I mean, GhostBSD is a separate  standalone project. I don't see any need for them to shut down their forums and tell other  users to move to true OS.  Like coming on their quarter to try them?  Yeah. So pretty much every distribution of true OS is that they can do that however they  want. They can run their own forums. They can have their own communities. It's up to them.  So we don't enforce any kind of give back from our distributions. So is that a good  answer?  Yeah, that's a good answer.  Because, I mean, there's been some talk because of project trident's a little bit more of  a special case because it really is the continuation of the true OS desktop. So we'll probably  have some overlap on the true OS forums with project trident at least for a while. But  I don't know if the plan is to eventually start up a new forum or whatever for project  trident. We just haven't worked out those details yet.  Other questions? Yes?  Maybe it was mentioned that you have an upcoming release date or event for a project trident.  Yes. Under that name, we are planning for our first release to come in about two months.  So we have scheduled for one more final release of true OS because we've been promising people  an 1806 release of true OS itself. For a while now, we're going to stick to that promise.  We will release true OS 1806. And then project trident will be releasing its own version  probably two months, the first version will probably be two months after 1806 using the  new systems and based off of that. One of the other changes with project trident, you  know how I mentioned the release schedules for true OS, there was stable and unstable.  With project trident, we're planning on only having one release schedule and that is a  stable base operating system, the stable version of true OS, but then we're going to have a  rolling ports tree packages. So you'll have atomic diffs for end user applications during  a release cycle and then we'll only update the actual base OS packages every six months.  So that's our plan for trident, again, we'll see how it goes. We're trying to keep it  quiet for the first time and make sure that things actually flow smoothly before we firmly  commit ourselves to dates, but that's what we're thinking of. Yes.  So if you're running to us, I'm not running to get a point to doing something. If I have  true OS and then project trident, is it an easy transition?  Yes, we actually have planned a full upgrade path directly from true OS to project trident.  We actually have within the true OS project right now, we have two different meta packages  that we install, one of them is true OS desktop and the other one is true OS server. So obviously  if you during the upgrade, if you have true OS server installed, okay, it'll keep you  on the true OS repositories and keep going with that. That's an easy transition. We had  talked about looking and if the true OS desktop package is there, it'll just immediately upgrade  you to project trident, but then there's a few people that are also wanting it's like,  okay, if that's there, maybe give people the option to upgrade to trident or upgrade to  ghost BSD. So we're looking into possibilities, maybe we'll have some kind of switch down  the road, but none of that's been finalized yet. Any other questions?  I guess I've clarified a little bit. Yes.  If the get company book says more or less a fork.  Yes.  Chris uses that for that word a lot. I don't like that word.  Yes.  He's used the term fork there. He uses the term downstream fork quite a bit in conversation  with him and stuff. He's trying to make it across that yes, it is different from free  BSD, but no, it is not separate from free BSD. We are still very much joined together.  We are still sending changes to them on occasion. We are still getting changes from them on  periodic that occasion. We try to keep in close with the free BSD community. It's not  like we're trying to say, oh, you know, so long we're going to do our own thing. It's  not a fork like that. So it's, I guess we just haven't found the right terms to describe  it, but yeah, that's basically what it is.  It seemed to be like you were hoping to track free BSD.  Yes.  And again, some of the changes that we've got from free BSD right now were, again, working  with free BSD people to get those into free BSD. With OpenRC, for instance, we would  love to help free BSD move to OpenRC. Base packages. This is something that a lot of  free BSD people have been wanting for a while. It still hasn't been rolled out or implemented  yet, but we're just a great test case of it can be done. Here's the fixes and patches  we've had to do to get it working. And we're working with them so that free BSD can use  package base as well. So we're trying to, even though we've got a bunch of diffs between  us and free BSD now, we're actually hoping that we'll get shorter over time. And then  maybe again, it'll get longer when we start, you know, working on some other new thing  that free BSD might need and we'll work on it and get it up and going and then send that  to free BSD again and try to sync it in. Which is, yeah. Hard to describe, but yes, we are  very connected to free BSD and we want to stay connected to free BSD. We don't want  to just say, you know, so long and, you know, be our own thing. Yes?  What's the support model for TrueOS?  Are you talking, what type of support are you talking about?  I'm assuming so it's a commercial offering, right?  Yes and no. It's actually a community offering by a commercial provider. So IX Systems does  not actually sell support plans for TrueOS. So it is all still just community support,  yeah.  But IX, does it sell part of that community as well?  Yes. And so a lot of the IX people, like the FreeNAS developers and stuff, they'll often,  you know, within the TrueOS community, if people have really advanced ZFS questions,  we'll say, hey, go ask on the FreeNAS forums or maybe we'll get a FreeNAS developer over  here and answer your questions over here because they go into such more detail on ZFS and the  storage side that we might never do. But we have so many pools of experts all over the  place, each of them focused on various parts of FreeBSD that we kind of see our, I kind  of see TrueOS as kind of like a melting pot of that and the glue to help bring people  into FreeBSD via TrueOS and then help them find all the communities and get hooked into  everywhere and become part of the community. Other questions? I don't know how much time  we've got. I'm just guessing.  We have 20 minutes.  Oh.  Actually, 10 minutes.  10 minutes.  We need a minute break.  Okay. Yes.  I have a question aside from TrueOS. I just want to add to the experiment, or to bring  IAIC systems to Europe.  Bringing IAIC systems to Europe, you would actually have to talk to Chris about that  in management. I am a lowly peon in the IAIC systems infrastructure. Yeah, Chris is actually  vice president of engineering, so he's involved in a lot more of those decisions. I'm just  one of the engineers.  Yes.  You mentioned OpenRC, packed space. You're so giving yourself freedom to say we're going  to test that and stuff.  Yes.  Are there things not in TrueOS that you would love to put into it, if you were king for  it?  There's always ideas getting thrown around. Whether we actually start doing it or not  is another matter, but that's the thing. With the computing world, it's always changing.  So even though we might not have something in mind right now, who's to say a year from  now, something really important doesn't come up. It's like, you know what? That's a really  good idea, and we try to do something like that. We really don't know. We're leaving  our options open.  One of the things with PCBSD and TrueOS, we've always been very, very flexible and very  reactive and very dynamic to what's going on in the ecosystem of Linux and BSD and pretty  much all open source projects.  So we try to keep that flexibility and just leave doors open so that we can start helping  other projects and things do that.  That's one of the other reasons I wanted to bring up all these differences from free  BSD. It's not trying to trumpet TrueOS, but I mean, we're open. We want to talk to people.  We want to help other distributions. We want to help NetBSD and OpenBSD.  If what we have tried and didn't work is any example, maybe learn from our examples, it  may be a six-month release would work great for NetBSD or DragonflyBSD. Maybe, you know,  just learn from us. We're here to help everybody whether you use our stuff or not.  That was kind of actually the whole reason I put this talk together. It's like, okay,  we've done a lot over the last several years. Let's just tell people what we've done, what  we've worked with, what didn't work, and this is what we've found that seems to work really,  really well.  Six months release schedule is probably easier to save than to do.  Yeah. That would be the easiest one to adapt in other ones. Of course, individual technologies  are on a, you know, case-by-case basis always.  Sometimes in a community, open source community, people might get paid new releases. Sometimes  it's hard to get people to push through.  And that's one of the reasons why we set up the distribution system for the NeutroS  repo, the way we did is we actually have the automation framework for doing it via Jenkins,  also baked into the repo. So we actually have a Jenkins setup file directly in that repo  as well that anybody can take and distribute to distribute their own Jenkins instance  to automate the creation of all the packages and stuff for them.  So we're trying to do that to help, you know, communities, help people that want to start  a distribution get up and running with as little effort as possible rather than, again,  expecting you to be a guru and know exactly which bits you need to flip here and there  within the source trees in order to build a custom distribution.  Yes.  I did not research this prior. I did notice that the mostly VBSD and back extension 2.0  like this one, you can see more of our FreeM네요 and graphic, Chao for my  Well, from what I understand,  they're actually looking at possibly giving us CUDA and stuff,  but mainly because we were still behind from Linux,  and most of that stuff was using Linux frameworks.  Now that the DRM work has gotten in and they can use some of those,  they're more open to turning on those bits in  the proprietary NVIDIA drivers so that we can get CUDA support and stuff,  because the underlying systems are there for them now.  Yeah.  But we still need to wait for them.  It's not necessarily in our hands.  So if you want to talk to NVIDIA and keep asking them for it,  by all means, please do.  Open CL support and CUDA support would be fantastic in the NVIDIA drivers.  The driver has all the things that  the place that they doesn't provide,  they need to have libraries to help them to actually use like a power.  They're not willing to go to do that.  But I've been able to compile Linux binaries that were using  the two libraries that run the final three-disk.  And they'll use the two that's in the driver, okay?  So they're actually a Linux binary and they can use their watchers.  Okay. Any last questions?  All right.  Thank you very much.  If you have any further questions,  I'll be down here or at the IAC systems booth if you want to talk anymore.  Thank you.  Please leave a comment exporting this file to output.  Okay.  Thanks for recording me.  Bye, yeah.  Bye bye.  Thank you and thank you very much.
Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_0_107.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_108_251.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_252_407.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_408_9299.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_9300_10223.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_10224_12947.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_12948_14831.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_14832_16763.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_16764_19271.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_19272_22427.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_22428_22487.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_22488_24431.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_24432_24791.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_24792_29039.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_29040_29087.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_29088_29327.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_29328_32879.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_32880_32927.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_32928_38507.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_38508_41183.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_41184_43127.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_43128_43847.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_43848_47399.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_47400_50723.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_50724_53003.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_53004_55091.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_55092_59447.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_59448_60947.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_60948_90491.png Ken_Moore__The_TrueOS_Difference_--_BSDCan_2018_30V_clQToRw_90492_90501.png
Alright, so before we get started, I just have a few quick questions that I always like to ask people before I ever give a talk like this. First one being, since we're at a BSD conference, everybody who uses open BSD, raise your hand. Everybody who uses net BSD, raise your hand. What? Nobody? Dragonfly BSD. And FreeBSD. Other. You. Okay. So, I just generally like to do lots of little quick polls for people right before I talk. Usually, I do give these kinds of talks at Linux conferences where nobody's ever heard of BSD, so I have to kind of explain what it is. So I always have to explain, okay, what FreeBSD is and how it's descended. That's fine. Since we're at a BSD conference, though, I can be a little more specific. So I assume most of you have heard about TrueOS before. Am I correct in that? Yes? Yes? Okay. Other hands. How many of you have not heard about TrueOS? Good. I don't need to explain myself then. Oh, wait a minute. Do you? Okay. You're good? Okay. So I don't need to go into too much detail. I mean, I'll give you a little bit of detail in here, but I don't have to go into gory details or whatever if you're already familiar with it. How many of you have actually used TrueOS at one point? All right. How many of you used TrueOS right now at the present time? Okay. How many of you ever used PCBSD? A few of you? Okay, good. That gives me a rough ballpark of what kind of audience we've gotten. Now, how many of you are interested in TrueOS but haven't heard any of the recent developments? Okay. Like the stuff that happened, what was it yesterday? Two days ago? Yeah, the blog post that came out a couple days ago. Are any of you familiar with that already? Yes? No? Okay. Well, I do go into a little bit more details on that at the end of this talk because this is kind of what this talk was going into is why what was announced is actually what's going where we're going going forward. So this will lead into that and explain the background of the project and why we're going where we've been heading and just haven't told people until now. That's always fun. And just for my own benefit, completely unrelated to that stuff, how many of you used the Lumina desktop? One of you? Oh, a few of you. You mean regularly or how many of you used it? How many of you used it within the last month? Okay. A lot more of you. Good. Now, are you using, those of you that are using it, are you using the latest release version on FreeBSD, which I think is 1.4.0? Or are you tracking the newer releases from the source repo, which I think is 1.4.3 at the moment? FreeBSD packages? OpenBSD packages? Yeah. Okay. That's kind of what I expected. What version was in the 1.8.0.3 TrueOS? 1.8.0.3 TrueOS. Yeah, I think that one's a little older. That's 1.4.1, I think. All right. Sorry, I've got two minutes. I'm trying to kill time. Anyone know any jokes? I try to be a comedian, but everybody just laughs at me. I don't get you every time. Yeah, almost there. Does anybody know how the recording system works? I heard it was supposed to be recorded, but do I have to stand right here? I've got the mic. Oh, this one. So I need to stand over here so people can see the slides. Over there? Okay. They're not recorded. Okay. So do you want me to stand over there out of the corner or something? Like over here. Yeah, that's what I was going to say. So if I'm in the corner, hopefully I'm not covering the slide. Yeah, that's true. I should probably post them somewhere then, shouldn't I? Yeah. Okay, I'll try and stand here. I tend to pace, but I will try to remain fixed. And that took the rest of the time. So, all right, welcome to my talk. This is the TrueOS difference. For those of you that aren't familiar with me, I'm Ken Moore. I work on the TrueOS project. I was part of the PCBSD project back in the day. I was one of the founding members of TrueOS when we made the name switch. And here to talk to you a little bit about it, shore up some things that people might be confused about, you know, enlighten people that weren't aware of things. So this is just a quick, very rough outline of what we're just going to go over today. I'm going to try and do a very quick history of TrueOS just to give you all the context of why we do things differently than FreeBSD and why we've decided to focus on these differences. And we'll go into changes from FreeBSD because TrueOS is based off of FreeBSD itself, but we change a number of things. And so I'll go into some of those. And then I want to go into some of the next steps, stuff that was mentioned in the release announcement a couple days ago, and go into, with all this context, I think a lot of that will start to make a lot more sense for why we're changing directions. So first off, PCBSD. Number of you said you were familiar with it, had even used it. So I hopefully don't need to go into too much detail on this, but it was started in 2005 by Chris Moore, who is my older brother, it's not me. And he started in 2005 as a desktop focused version of FreeBSD release, and the original version of PCBSD was based off of FreeBSD 6.0. He gradually started creating and adding utilities to PCBSD at the time, specifically for shoring up some of the weaknesses. PCBSD was based off of KDE 3. So he created a new network manager in QT 3 to go along with KDE because the KDE network manager wasn't working properly with FreeBSD, things like that. So eventually he created some utilities such as PCSys install, which is a scriptable installer for FreeBSD rather than the text installer. PCNetManager is the network manager I mentioned a moment ago, and there's a number of other ones. All of the utilities that he created for PCBSD were submitted back to FreeBSD as ports. I believe most of them appeared in the sysutils category, and they were all PCBSD dash something in the ports tree. Gradually he started delving into adding and customizing the FreeBSD ports themselves on a regular basis because he discovered that many of the ports, the build options for the ports were not designed for desktops, like they had all the graphical stuff turned off, and then when you run it from the desktop, you wonder why things don't work properly. So he had to start building his own ports tree and building his own packages with different flags turned on just so it would integrate properly. So he started maintaining a fork of the FreeBSD ports tree. I joined on the team a little bit later after that, and PCBSD kept going till the 10 series, FreeBSD 10. And then in the end of 2015, very beginning of 2016, we decided to make the plunge. We had always been based off of FreeBSD releases for PCBSD. But then we started, it's like, you know what? Every time FreeBSD release comes out, we would determine that it was already at least a year or two obsolete for modern laptops. It would never work with stuff that had come out within the previous year or two. So since we were based on releases, even though something was brand new for us to the rest of the community and the consumers, it felt like, oh, that's old news. It doesn't work on anything new. So we started rolling builds of PCBSD using FreeBSD current instead of FreeBSD release branch. So I think it was December of 2015. So I put the end of 2015 there. But by December of 2015, we actually had a rolling build of FreeBSD current at the time, publishing pre-release images of FreeBSD 11.0 from the current tree. As part of this move to current, though, we also started using some new systems in FreeBSD which were planned and scheduled by the FreeBSD team for release in 11.0, namely package base. So this is something that FreeBSD still doesn't have in the 11.0 series, and they're still talking about whether it's going to get put into FreeBSD 12 or not. But PCBSD or TrueOS has been using package base for almost two years now. We've actually been using it and testing it and committing fixes to it right back to FreeBSD. At the same time, though, Joe Maloney came on board at the TrueOS project, and he was very, very interested in this new system called OpenRC to help replace some of the service management systems on FreeBSD. Chris and I had been looking at a lot of alternative service management systems like NoSH, LaunchD. There was one or two other ones as well. We've been evaluating them for a while, trying to find something to help make things boot up faster and easier to manage. So when Joe Maloney came by and he's like, yeah, I actually have a build of OpenRC on FreeBSD over here, we were very interested and we started running some builds with it and testing it and toying with it for a while. So in 2016, early 2016, after we had been rolling these current builds of FreeBSD for a few months, we decided that, okay, so much has actually changed underneath the hood from these rolling release builds to the release builds of PCBSD that the upgrade path was already completely shattered and broken. There was no way for somebody to go from a release of PCBSD, I think 10.3 or 10.2, was the last release of PCBSD. And then we had these rolling release images, but there was no seamless upgrade path. It was a really complicated mix of hacks and manual commands and it got ugly really, really fast trying to move to these new systems of package base and OpenRC. So we decided that at that time, okay, so much has changed, we've ripped out so much of the old system that was there for PCBSD and we've put in so many new subsystems, we didn't really feel right calling it the same thing anymore because we were also focusing from the true OS perspective on different systems. We weren't just doing desktop stuff anymore. We were now talking about configuring FreeBSD. We were tinkering with the FreeBSD underlying system itself. We were no longer just being a desktop built on FreeBSD, which was the point of PCBSD at the time. So we announced that the PCBSD project was ending and that the true OS project was the next evolution of it to take its place, much like a phoenix rising from its own ashes. So that was the beginning of the true OS project in early 2016 and it really had a very different focus. First step is that it was consumer focused instead of desktop focused. So we weren't just doing a build of FreeBSD and then slapping a desktop on top like KDE4 was what we were using at the end of the PCBSD days. We were no longer just a desktop distribution. We were literally a customized version of FreeBSD, implementing a lot of changes in FreeBSD that FreeBSD, people who are following FreeBSD releases wouldn't have for another year or two depending on when the next scheduled release was because we were being based off the current branch of FreeBSD, not the release branch of FreeBSD. So our timetables were greatly accelerated from standard distributions of FreeBSD. We basically moved from a downstream consumer of FreeBSD releases just using whatever FreeBSD gave us and actually moved into an active tester and contributor back to FreeBSD because we were providing FreeBSD developers users and people that were testing their changes very quickly after they were committed to FreeBSD head and providing active response right back to them so that they could get things, issues worked out and resolved well before the FreeBSD release process ever got kicked off. One of the other ways that we would do this is actually emerging FreeBSD developer branches into base ahead of time. If they got bogged down in some kind of issue either in fabricator or something, we would actually merge those branches and work with that developer to get their changes put into base ahead of time so that they can prove to the FreeBSD project, yes, it looks like it's a drastic change, but don't worry, it still does work very well. We have live builds, see if it works fine. So we would do stuff like that and we were very instrumental, I won't say exactly very instrumental, but we helped with that considerably with regarding the new graphic stacks for FreeBSD involving the newer Intel drivers and DRM next stuff. We were pulling those in and using that and providing feedback on that very, very early. So okay, that's the end of the history of TruOS. That kind of takes you from PCBSD up to TruOS at the current time. Do you have any questions on history before I go into other additional differences from FreeBSD? Just showing how we kind of move from a desktop distribution of FreeBSD to basically a customized version of FreeBSD current in the back. What do you say you couldn't really upgrade from rolling release? Does that mean every time you wanted to upgrade you'd have to wipe and retake? No, no, no. So the problem was switching trains, if you will. We couldn't go from the stable version to the rolling release version. Once you were on the rolling release version, you could upgrade and stay on that fine, but there was a hard break between the two and we couldn't find an easy and automated way of automating that. So that was a very clear logical break between the PCBSD days and the TruOS days as we can point to that because there really was no easy bridge. That's your watershed. Yeah. It was a very clear defining moment for us. Yes? It sounds like you're pushing stuff a lot faster than FreeBSD, you're pushing more stuff in quicker. Do you have any special methodologies to make sure that it wasn't breaking stuff? You and that testing? I'll get into that in just a second. Yes. So, okay, yeah, that's just the general history. Let's go into a few more of the differences now of what's different now in TruOS compared to FreeBSD because I've said FreeBSD current many times. Obviously, there's differences there between FreeBSD current and FreeBSD release. That's a given. But what does TruOS add to FreeBSD current and what do we do differently? First step, release engineering. Obviously, since we're based off of current, we're no longer following FreeBSD's release schedule. So we had to start providing as a project our own release engineering, our own release schedule. So we've tried many, many different types of schedules for releases among the PCBSD and TruOS days from weekly rolling release images to monthly images to mixtures of long-term support releases. And what we settled down on is actually one that works really, really well for us right now. And that is a six-month release, which we actually got the idea from OpenBSD. For any of you OpenBSD guys here, thank you. It was a great idea. So that every six months, you get a stable release. That's what we call it on TruOS. We have two branches. We have stable and we have unstable. So stable is a six-month release. There are no changes to base or ports in that time unless there are like major security issues. That's actually why we issued the 1803 release of TruOS halfway through our six-month cycle in response to Spectre and Meltdown and stuff like that. It's significant enough we needed to push out another release image ahead of time. This, the reason we had something like this was this was perfect for derivative products or appliances. We had a lot of people that wanted to use TruOS either on their servers or build their own little appliance off of it. But if you're having weekly updates to it, that's very, very disruptive to end users, specifically enterprise users that expect it to be like a static appliance. They don't want it to change. So why does it keep trying to automatically change things? So stable releases were perfect for that because six months is a long enough period of time that it's still easy to support it for us because we're a much smaller team than FreeBSD. It gives us a smaller window. It's like, okay, yes, we will support that stable version for six months. And then it's also long enough for the end user because it's like, okay, once I install it, I don't have to worry about it for six months. Unstable branch of TruOS is much more of our rolling release branch. So this is where we released much, much more faster. We would do it sometimes once a week. We tried to shoot for once a month, but we weren't necessarily on a fixed schedule. So we told people it could be anywhere from every week to every month for a new image of unstable. But what was unique about unstable was that it was the combination of unstable base and unstable ports. So if you wanted the new applications and stuff, we kept telling people you have to go to unstable. That's where we do all the new builds and stuff like that. But the unintended consequence of that was that you were also getting all the new base bits from FreeBSD current at the time. So both of them were rolling in sync at all times. All right. Any questions about release engineering before I move on? So this is what TruOS is using right now. We still have this, this is our schedule and this is our release engineering. As part of our release engineering process, we have quality assurance processes. We actually have fully automated build systems running all the time. And as part of that, we actually have a bunch of QA procedures built into it as well. So we try to catch things when building the full ports tree, for instance, we have a list of what we call essential packages to basically alert us if one of our automated builds, one of these packages fails to build. It's like, okay, something's going on in the ports tree right now. When all the flavors for Python got put in, needless to say, we were getting lots of alerts from our build system because Python 2 and Python 3 were some of our critical ports and things were no longer failing to build, were failing to build for quite a while. So we have things like Python clang. Because we do have the desktop side of TruOS, we add things like Firefox into there and a few of the other browsers, Chromium. So again, if one of those doesn't build, we consider that a bad ports tree and then we have to work on the ports tree and then trigger another build until we can get a good ports tree, a good build before we would consider releasing it. By the same token, we also check things from base. So bootability with the latest FreeBSD base, we would check the bootloader. We would check all the base packages and make sure that we could update between one set of base packages to another set of base packages. Since it was still highly experimental from FreeBSD itself, we did a lot of checks there. Plus, we did a lot of manual checks. So we would always install many times, either into virtual box instances, onto laptops, onto desktops. We would try to manually install and test these images in several places before we would issue a new set of updates as well so that we could actually get the hands-on test. That's where we would find out, for instance, if, oh, yeah, the driver is there, like, for instance, the NVIDIA driver. It's there, it built, but, oh, wait, NVIDIA added another version of their driver and the latest driver now drops support for all these cards, so we need to try and detect and fall back to, you know, older versions of the NVIDIA driver for particular systems and, you know, things to watch out for. That's where, that's the phase where we would have noticed things like that because we were actually running it on physical hardware and we ran into some of those things. Make sure that networking works in various types of situations, check that removable devices are working, things like that. Yeah. The automated checks is mainly just for builds. Does it compile? Do we get a package out of it? Using, like, the new versions of Clang and things like that, that was not actually running it. Running it would be part of the manual test where we would actually physically install and run a whole lot of things. Yeah. Mainly because we tried to pick certain packages as, like, bellwether packages for entire systems of the port street because if you try to wait until every package from the port street builds, we're never going to have a release. At any given time, there's always stuff. Yes. Exactly. And we do have those lists afterwards, but the list of packages that we have would be what sends us the alerts as to whether or not it requires manual interaction to go through and fix the port street or if, okay, this at least passes the smell test, then we'll go through and look at the lists of other ones. Yeah. Exactly. So FreeBSD ports already has a bunch of smell tests like that and checks for automated systems like that. This wasn't necessarily to alert developers that their port is broken because FreeBSD port team was already handling that and does regular builds like that. This is more from our side for a release engineering is, like, we cannot release if these 50 packages are not available. So those would be, again, our critical bellwether packages. If some minor, you know, library package on the side was failing to build, okay, it's nice, but nobody's complaining. It's not considered critical to our use case. So, and we would take requests for new essential packages and things to add to the list. So it's grown over time as more and more people have requested things. Yes. When you say you come across like graphics drivers like Nvidia drivers that happens to drop an older car, do you then have to go up a decision to we want to drop an older car in support in ours or keep it? No. So when I talked about the Nvidia driver in particular, this has happened a few times with the Nvidia driver. The Nvidia driver port is always just the latest driver from Nvidia. But every so often, Nvidia drops and creates a new legacy driver. So they have the 304 driver, the 340 driver, and then the current one right now I think is 390 or something, but that one's still rolling with whatever the latest is. Every so often when they create a new legacy driver, people that had the latest in driver installed will still, when they upgrade, they'll still get the latest driver, but that driver might not be, it might not have the same support as the new legacy driver, and they actually need to roll over to the legacy driver instead. So you actually have to do a quick check to say, okay, usually we can't automatically convert people like that, but we can at least warn people of it ahead of time saying, hey, this driver might not work if you're having any graphics issues, run this one command to replace the latest driver with the new legacy driver. So we've had to do that a few times, but it lets us catch things like that and at least warn people ahead of time. We do include multiple versions of the new driver installed. Yeah, a package repo will have all the versions of the drivers, but you have to actually replace one of the drivers with the other one with your packages, because the upgrade can't do it seamlessly. All right, service management. I already mentioned Open RC a little bit, so this is one of the other big changes that we have been championing and pushing for FreeBSD is that we should use OpenRC as a replacement for the RC.D system in FreeBSD because it is a state aware management of services. You can actually get statuses of all your services rather than the RC.D system where only a handful of the services would actually report whether they're running or not. Most of them just return errors if you ask for status, even though they might be running just fine. Proper dependency handling of services. One of the things about OpenRC was that you can say, okay, yeah, I want to turn on this service at boot, but then the service says inside of it, oh, by the way, I need these other two services. You don't have to manually go read the documentation and figure out, okay, so if I want to turn this one on, I also have to turn this one and this one on. OpenRC is really good about that and says, oh, you turned this one on, but it says it needs these. Those are also available, so it will start them up beforehand so that the one you want does work without having to do a lot of hand holding or without having to do a lot of manual reading and configuring. And then the other thing that we got as a side effect is that OpenRC really is the next generation of RC. It's the same kind of system, same methodology, but it's written as a C binary with shell-like service files, so you just get much faster operations. So the boot times went drastically down and we got a lot of other benefits from switching to OpenRC at that time. And we're actually still pushing towards FreeBSD and trying to get FreeBSD to move over to this. This is one of the things that we have been trying to champion for FreeBSD Current saying, hey, you might want to consider switching to this. It will restart services. OpenRC actually has two different types of service management. The standard Start, Stop, Damon is very similar to FreeBSD as it starts it and if it stops, it stops, but at least you get warnings now of when you check the status. It says, oh, yeah, that service crashed. There's an additional type of supervisor within OpenRC called Supervise Damon where what it will do is if the service specifically says I am supervised, it will launch it, but if it ever crashes, it will automatically restart it, but then it will keep a counter of when was the last time the service was started and how many crashes has it had since it was manually started. So if you just do an RC status to see the status of all your services, you might see something that says, okay, there's the times of all the services and some of them will have a parenthesis with like five inside of it. This has crashed five times and been restarted five times automatically. Gives you an idea that, okay, you might want to go check on that. Yes? Is there a way to disable that functionality? Is there some security? Yes. It's one flag within the service file. It's really easy to switch back and forth. Yeah. And that's why I said it's on a service by service basis. So some of them might be supervised. Some of them might not. It just depends on what you want. All right. One of the other changes that TruOS has, we have a very, very different rules of conduct. I know this is something that came up recently and I was asked to put this in here and I think a lot of people care, but really, we don't care. All we care about is the code. That's what it comes down to. As long as you can behave civilly and send in code, that's all we care about. Other than that, go your own way. That's our rules of conduct. In addition, our contributor policies are a little bit different in that we are completely GitHub based. We do not use SVN. We actually use GitHub for everything. All of our pull requests and reviews and merges are all completely public and anybody can go back and look through them and view them very easily. That's just like most other things like subversion stuff. But with GitHub, it just makes it really, really transparent and easy for anybody to browse it and search that really quickly. It streamlines the submission process considerably. Literally for all you need in order to send in a patch to the TruOS project is a web browser. You can go to our repo. You can find the file, edit the file directly there within your web browser, open a pull request in three clicks and you can be done and send in a patch in literally, you know, ten minutes or less, depending on the size of the patch, obviously. We also have a one week timeout on patches. And by this, what I mean is if nobody has, if the maintainer or reviewer times out after a week, after a pull request has been sitting there and there's been no objections to the patch or whatever, then one of the TruOS developers will review it at the end of that week and just commit it or deny it right there by fiat. No questions asked. We do not have pull requests or patches that sit in limbo for a year or two. Everything is dealt with and handled on a very responsive basis. So that is one of our things that we are very, very passionate about. If you have a change and you send in a change, we will respond to you in a very timely basis. Most of the pull requests, you will get a response or get it merged in within a day or two. That's typically our process. Yeah. And that kind of happens, especially as the projects get bigger. So we put this in place really early with our system on GitHub and we have been very strict about holding to this kind of timeout because we do not want to let PRs back up. We do not want to let issues continue to back up. So, I mean, feature requests and stuff, that is separate than sending a PR. If you have a patch and you send that in, that will be dealt with instantly. Now, just somebody asking, hey, I want this. Why don't you do this for me? Yeah, that might sit for a while, depending on if somebody wants to get around to it. That's different than actually somebody sending in code. Package management updates. I mentioned that we do have base packages in addition to what I call ports packages because it's not just packages. They are packages from the port street. So we have package set up with two repositories, one for base, one for packages so that we can update one or both simultaneously as need be. So the base package repo, for those of you that aren't aware, this will contain the package files for things like installing the FreeBSD kernel, runtime packages, things like send mail, the dash develop, those are the development symbol files for each of the individual packages and all sorts of other ones. So it's basically broken up. I think there's 120 different packages within the base package repo. That's how it breaks down. And then we have the ports packages. The other thing is that PC update manager. Again, FreeBSD doesn't use base packages right now. You can't use the exact same methods that FreeBSD does in order to update your system because the back end is completely different with the base packages. So in PC update manager, what we quickly discovered is that we needed an update script, PC update manager is written completely in shell, but it self-bootstraps itself. And this is really important because it gives us a mechanism whereby when we're doing a release and we have everything staged and ready, if we find an issue actually performing the upgrades on our test systems, we don't have to completely rebuild all of the release packages again and all the ISOs and everything. All we have to do is patch PC update manager because when it runs, it will self-bootstrap itself to the latest version to make sure that you have the patches for that update. So that lets us get a very, very quick turnaround to fix any type of update issues without having to issue completely new package sets, all 60 gigabytes of packages from the ports tree. So we discovered that very early that we needed a mechanism like that just to fix and resolve issues like that on a very timely basis because problems with updates are something that are a killer for distributions and stuff. You can't update properly, then you're going to have a lot of troubles. So that's where we are with TrueOS right now. Do you have any questions on that before I take us to the new stuff? Yes. How well does it operate under Zen? Under Zen. I haven't tried to understand. I actually don't try as much of the virtualization stuff. We use a lot of virtual box and VMware and VHive. Zen, I know some people use it, but I haven't heard them complaining so it might work perfectly fine. I just don't know. I just don't use it. Yeah. What's the status of TrueOS Pico? TrueOS Pico is a project that Chris developed which is pretty much a static image for the Raspberry Pi itself, but he kind of got sidetracked after getting promoted to VP of engineering at IX systems and hasn't had as much time to work on that. So it's still there and what's there works. We haven't gone through and disabled it, but it's still limited to the Raspberry Pi 2. He hasn't created the new images for Raspberry Pi 3 and some of the other boards. Do I talk to him if I have questions on? Yes. Please talk to him if you have questions. Yes. Everything you do is on GitHub and all the other stuff. I think some people may worry, okay, this is a commercial product. What is their secret sauce, binary bits if you don't share or Facebook? No. Something that TrueOS has, we have no private repositories. We have completely public repositories. We don't have any closed source bits that we dump in or whatever. It literally is free VSD just taken to the next level, still completely transparent and open source. Any other questions about TrueOS as is? Yes. IAX systems is the owner slash sponsor of TrueOS. Back in the PCBSD days, Chris started the project by himself and then he was purchased by IAX systems so that it became a part of IAX systems and he was hired to continue working on the project. Effectively, it got folded into IAX systems. IAX systems is officially owning it and sponsoring it and they're the ones that are creating all the build servers and running the tests and many of the IAX systems employees are paid to work on this and there's a lot of development effort put into it. Yes. Is TrueOS used within IAX systems? All over the place. Yes. Other questions? All right. Well, let's go on. Okay. So that's where we are right now with TrueOS or I should say two months ago with TrueOS. So what's going on with TrueOS right now? We just had an announcement a couple days ago about a shift in direction for TrueOS and that's kind of what I want to talk to you here. So TrueOS is changing. We announced a couple days ago that TrueOS is growing into a distribution platform for anybody to easily build their own custom distribution of FreeBSD or TrueOS with just a couple of quick commands. So it is a full-blown, I think Chris is using the term downstream fork of FreeBSD. So that repo there, if you go to the github.com, TrueOS, TrueOS repo, just like FreeBSD has their FreeBSD slash FreeBSD repo, the read me on that repository if you just scroll down to the bottom will give you a long list of changes from FreeBSD, some of which I have listed here. One of them open RC. I've already mentioned that we've been using it for a while and that's one of the differences from FreeBSD at the moment. Package, Poudre and the root NSS certificates are all built into the base operating system itself. You no longer have to worry about package changing versions in the middle of an update because the release cycles are so much faster than FreeBSD. We can stabilize package for a few months at a time and then only roll out updated versions of packages with those release cycles. The root NSS certs because I believe the note Chris put on that in the read me was because not being able to use HTTPS initially is just dumb. I think that's basically what he said. So you get HTTPS support and encryption support out of box. And then Poudre. So one of the things that is specific to this to turn it into a distribution platform is the build system of it itself has now been collapsed down to a single JSON configuration file. We call it a build manifest that you supply to the build and it will build all of the base, all of the ports packages, create the package repositories for you, as well as apply any of your custom install overlays, build overlays, build configuration changes. It's basically the one file to rule them all. And you can literally build your own distribution of FreeBSD. I think it's three commands. You fetch the repo, give it the manifest and then run make, build, world, build kernel, make, build packages, make release. And that does everything. It generates, it signs all your packages, does the whole nine yards. So that's what we are going. So this would help, will help downstream consumers of true OS to very easily customize and build their own appliances with just the individual packages they need but might not be pointing to the true OS package repositories anymore. So they can stabilize and do their own updates on their own schedule instead of being fixed by what we decide to do at the true OS project. It gives the freedom to everybody. But we are going to continue to release and update our own package repositories on the fixed schedules like we always have as well. So again, it's more freedom for all of our users. In addition to that, we are also changing the organization of the project a bit. The desktop side of true OS, which again was kind of minimized a little bit with the change to true OS because we were focusing more on changing the base system, is actually getting split off as a new desktop based distribution of true OS called Project Trident. This is a completely separate project. It is community based and community owned. And it is going to be something completely new as a distribution of true OS. Similarly, GhostBSD is going to become a desktop distribution of true OS rather than following the freeBSD releases as well. And then along with the system, we anticipate that we will have many more new distributions of true OS to announce in the near future based from either corporate products or other user products or community projects as well. And that's literally all I had. So with regards to the split of the project, I am actually taking the lead and running Project Trident as well. So we do have a website that we just put up. But Chris, since me and Chris have kind of historically done the entire thing together, he's going to focus on the base stuff and head up true OS within IAX systems and then I'm going to head up Project Trident within the community. Yes. So Trident and Ghost are both desktop systems? Yes. Why the split? What's the difference between them? GhostBSD has actually been around for quite a while as a distribution of freeBSD specifically focusing on the Matei and XFCE desktops. Yes. Yes. That's Eric Turger there. He runs GhostBSD. Yeah. He created it. So it's kind of an analog to PCBSD. PCBSD was KDE focused. GhostBSD was GTK and Matei and GNOME focused. Although not GNOME anymore. It's Matei and XFCE. So it's just different, similar ideas, but just different ways using different tools and stuff. So GhostBSD, what's your latest release for GhostBSD? 11.1. 11.1 based on freeBSD 11.1. Okay. There you go. Yes. In the back. Sorry. Are you doing true server? What was that? Is true server going to remain as a product? Yes. So one of the things is because we're spinning off the desktop side to Project Trident, what we're doing is we're trying to take the true OS repository and take it much, much closer to freeBSD. Aside from the changes I listed there, I mean, we've always had questions from people on the freeBSD side who didn't want to take changes from true OS because they were worried about getting desktop bits. And it's like, no, no, no. It's like we've been focusing on the underlying systems and no, there's nothing desktop there, but we're formalizing that a lot more. So that true OS will probably move to server focused releases and leave the desktop focused releases to Project Trident. So we've historically had both server and desktop releases for true OS for the last two years, but people still tend to say, oh, that's just a desktop when, no, it's a variation of freeBSD. So we're just kind of formalizing that so that true OS is known as the underlying system. It is a server or you can redistribute it as a desktop. Yes. I'm curious what the relationship between true OS and free NAS are in terms of their code base. How much? No, no, no. The shared development. Free NAS is also an IAX systems project. True NAS is based off of it. Free NAS is based off of freeBSD. And it is not based off of freeBSD releases as much as it is based off of freeBSD stable branches because, once again, releases are too slow, so they follow the stable branches. And there has been a lot of duplication of effort to try and keep that base up to sync by the same token true OS and the other projects trying to, again, keep their base up to sync with freeBSD with whichever branch they're following. We are currently evaluating within IAX systems whether free NAS can move to true OS. And we're doing prototypes. Other than that, we'll wait and see. See what comes of it. Over here. Would it keep developing the Lumina desktop? Yes. So I actually am the author of the Lumina desktop and that's one of the things that we're going to do within Project Trident. So Project Trident is going to continue following the same tact that true OS desktop side has been doing for a while, which is Lumina desktop, that uses the Lumina desktop by default, but then it also emphasizes and tries to create a much more pureBSD system instead of relying on a lot of the Linux subsystems like Pulse Audio and stuff. We're actually going to try and do a lot more of that within Project Trident to keep it pure to freeBSD and help enhance development within the freeBSD community. That's one of our goals. Other questions? Yes, back there. Now you were saying you can fork true OS over. Say I want to do that for my appliance. Make the changes that I need. How it is to then pull your changes from the next release into mine. Very easy. Actually, have you used GitHub all that much before? A little bit. GitHub makes forking and then sending changes back and forth between forks incredibly easy. All right. So you can literally just fork our stuff at a particular tag. We're actually doing very smart tags of the different builds and versions of the source tree on GitHub as well. So you can specify, okay, I want to fork true OS at release tag, whatever it is, blah. It could be an official release or it could be one of the intermediate development releases. It's up to you. Do your builds and then literally on your thing say, okay, now I want to re-merge or re-sync with the upstream fork and do all that and then you just might have to deal with merge conflicts for changes that you have to do with yourself, but it's very, very easy to keep that up to date. That's actually how true OS has been maintaining its fork of free BSD for a long time because we re-sync with the free BSD repositories on a very frequent basis as well. And actually on the true OS, true OS GitHub repository in the very top of the readme is the tag with the latest date that they have synced with free BSD head. So that we keep up to date. So as changes are getting put into free BSD, they will also end up in true OS and then by the same token, we're hoping to help push more stuff from true OS into free BSD as we provide the testing platform for free BSD developers to test and approve changes and stuff. Trying to help make it easier everywhere around. Yeah. Yes? IAIC systems is sponsoring project right there. Actually the first sponsor in helping us get everything spun up and going. But IAIC systems has always looked at it ever since the PCB SD days as really a goodwill gesture and an R and D for a lot of the other mechanisms within IAIC systems because all the products within IAIC systems are based off free BSD. It was very helpful to have a small team on the PCB SD side of things constantly pushing the boundaries and trying new things and developing new technologies. So it was that plus marketing. We go to conferences, we talk about IAIC systems. There's all sorts of benefits like that. I'm sure if you talk to different people at IAIC systems, you'll get different answers from every single one. But that's the one I've always seen and heard. Yes? Is there a plan to unify true OS and the GhostBSD community? No. I don't think there are any plans to unify the communities. I mean, GhostBSD is a separate standalone project. I don't see any need for them to shut down their forums and tell other users to move to true OS. Like coming on their quarter to try them? Yeah. So pretty much every distribution of true OS is that they can do that however they want. They can run their own forums. They can have their own communities. It's up to them. So we don't enforce any kind of give back from our distributions. So is that a good answer? Yeah, that's a good answer. Because, I mean, there's been some talk because of project trident's a little bit more of a special case because it really is the continuation of the true OS desktop. So we'll probably have some overlap on the true OS forums with project trident at least for a while. But I don't know if the plan is to eventually start up a new forum or whatever for project trident. We just haven't worked out those details yet. Other questions? Yes? Maybe it was mentioned that you have an upcoming release date or event for a project trident. Yes. Under that name, we are planning for our first release to come in about two months. So we have scheduled for one more final release of true OS because we've been promising people an 1806 release of true OS itself. For a while now, we're going to stick to that promise. We will release true OS 1806. And then project trident will be releasing its own version probably two months, the first version will probably be two months after 1806 using the new systems and based off of that. One of the other changes with project trident, you know how I mentioned the release schedules for true OS, there was stable and unstable. With project trident, we're planning on only having one release schedule and that is a stable base operating system, the stable version of true OS, but then we're going to have a rolling ports tree packages. So you'll have atomic diffs for end user applications during a release cycle and then we'll only update the actual base OS packages every six months. So that's our plan for trident, again, we'll see how it goes. We're trying to keep it quiet for the first time and make sure that things actually flow smoothly before we firmly commit ourselves to dates, but that's what we're thinking of. Yes. So if you're running to us, I'm not running to get a point to doing something. If I have true OS and then project trident, is it an easy transition? Yes, we actually have planned a full upgrade path directly from true OS to project trident. We actually have within the true OS project right now, we have two different meta packages that we install, one of them is true OS desktop and the other one is true OS server. So obviously if you during the upgrade, if you have true OS server installed, okay, it'll keep you on the true OS repositories and keep going with that. That's an easy transition. We had talked about looking and if the true OS desktop package is there, it'll just immediately upgrade you to project trident, but then there's a few people that are also wanting it's like, okay, if that's there, maybe give people the option to upgrade to trident or upgrade to ghost BSD. So we're looking into possibilities, maybe we'll have some kind of switch down the road, but none of that's been finalized yet. Any other questions? I guess I've clarified a little bit. Yes. If the get company book says more or less a fork. Yes. Chris uses that for that word a lot. I don't like that word. Yes. He's used the term fork there. He uses the term downstream fork quite a bit in conversation with him and stuff. He's trying to make it across that yes, it is different from free BSD, but no, it is not separate from free BSD. We are still very much joined together. We are still sending changes to them on occasion. We are still getting changes from them on periodic that occasion. We try to keep in close with the free BSD community. It's not like we're trying to say, oh, you know, so long we're going to do our own thing. It's not a fork like that. So it's, I guess we just haven't found the right terms to describe it, but yeah, that's basically what it is. It seemed to be like you were hoping to track free BSD. Yes. And again, some of the changes that we've got from free BSD right now were, again, working with free BSD people to get those into free BSD. With OpenRC, for instance, we would love to help free BSD move to OpenRC. Base packages. This is something that a lot of free BSD people have been wanting for a while. It still hasn't been rolled out or implemented yet, but we're just a great test case of it can be done. Here's the fixes and patches we've had to do to get it working. And we're working with them so that free BSD can use package base as well. So we're trying to, even though we've got a bunch of diffs between us and free BSD now, we're actually hoping that we'll get shorter over time. And then maybe again, it'll get longer when we start, you know, working on some other new thing that free BSD might need and we'll work on it and get it up and going and then send that to free BSD again and try to sync it in. Which is, yeah. Hard to describe, but yes, we are very connected to free BSD and we want to stay connected to free BSD. We don't want to just say, you know, so long and, you know, be our own thing. Yes? What's the support model for TrueOS? Are you talking, what type of support are you talking about? I'm assuming so it's a commercial offering, right? Yes and no. It's actually a community offering by a commercial provider. So IX Systems does not actually sell support plans for TrueOS. So it is all still just community support, yeah. But IX, does it sell part of that community as well? Yes. And so a lot of the IX people, like the FreeNAS developers and stuff, they'll often, you know, within the TrueOS community, if people have really advanced ZFS questions, we'll say, hey, go ask on the FreeNAS forums or maybe we'll get a FreeNAS developer over here and answer your questions over here because they go into such more detail on ZFS and the storage side that we might never do. But we have so many pools of experts all over the place, each of them focused on various parts of FreeBSD that we kind of see our, I kind of see TrueOS as kind of like a melting pot of that and the glue to help bring people into FreeBSD via TrueOS and then help them find all the communities and get hooked into everywhere and become part of the community. Other questions? I don't know how much time we've got. I'm just guessing. We have 20 minutes. Oh. Actually, 10 minutes. 10 minutes. We need a minute break. Okay. Yes. I have a question aside from TrueOS. I just want to add to the experiment, or to bring IAIC systems to Europe. Bringing IAIC systems to Europe, you would actually have to talk to Chris about that in management. I am a lowly peon in the IAIC systems infrastructure. Yeah, Chris is actually vice president of engineering, so he's involved in a lot more of those decisions. I'm just one of the engineers. Yes. You mentioned OpenRC, packed space. You're so giving yourself freedom to say we're going to test that and stuff. Yes. Are there things not in TrueOS that you would love to put into it, if you were king for it? There's always ideas getting thrown around. Whether we actually start doing it or not is another matter, but that's the thing. With the computing world, it's always changing. So even though we might not have something in mind right now, who's to say a year from now, something really important doesn't come up. It's like, you know what? That's a really good idea, and we try to do something like that. We really don't know. We're leaving our options open. One of the things with PCBSD and TrueOS, we've always been very, very flexible and very reactive and very dynamic to what's going on in the ecosystem of Linux and BSD and pretty much all open source projects. So we try to keep that flexibility and just leave doors open so that we can start helping other projects and things do that. That's one of the other reasons I wanted to bring up all these differences from free BSD. It's not trying to trumpet TrueOS, but I mean, we're open. We want to talk to people. We want to help other distributions. We want to help NetBSD and OpenBSD. If what we have tried and didn't work is any example, maybe learn from our examples, it may be a six-month release would work great for NetBSD or DragonflyBSD. Maybe, you know, just learn from us. We're here to help everybody whether you use our stuff or not. That was kind of actually the whole reason I put this talk together. It's like, okay, we've done a lot over the last several years. Let's just tell people what we've done, what we've worked with, what didn't work, and this is what we've found that seems to work really, really well. Six months release schedule is probably easier to save than to do. Yeah. That would be the easiest one to adapt in other ones. Of course, individual technologies are on a, you know, case-by-case basis always. Sometimes in a community, open source community, people might get paid new releases. Sometimes it's hard to get people to push through. And that's one of the reasons why we set up the distribution system for the NeutroS repo, the way we did is we actually have the automation framework for doing it via Jenkins, also baked into the repo. So we actually have a Jenkins setup file directly in that repo as well that anybody can take and distribute to distribute their own Jenkins instance to automate the creation of all the packages and stuff for them. So we're trying to do that to help, you know, communities, help people that want to start a distribution get up and running with as little effort as possible rather than, again, expecting you to be a guru and know exactly which bits you need to flip here and there within the source trees in order to build a custom distribution. Yes. I did not research this prior. I did notice that the mostly VBSD and back extension 2.0 like this one, you can see more of our FreeM네요 and graphic, Chao for my Well, from what I understand, they're actually looking at possibly giving us CUDA and stuff, but mainly because we were still behind from Linux, and most of that stuff was using Linux frameworks. Now that the DRM work has gotten in and they can use some of those, they're more open to turning on those bits in the proprietary NVIDIA drivers so that we can get CUDA support and stuff, because the underlying systems are there for them now. Yeah. But we still need to wait for them. It's not necessarily in our hands. So if you want to talk to NVIDIA and keep asking them for it, by all means, please do. Open CL support and CUDA support would be fantastic in the NVIDIA drivers. The driver has all the things that the place that they doesn't provide, they need to have libraries to help them to actually use like a power. They're not willing to go to do that. But I've been able to compile Linux binaries that were using the two libraries that run the final three-disk. And they'll use the two that's in the driver, okay? So they're actually a Linux binary and they can use their watchers. Okay. Any last questions? All right. Thank you very much. If you have any further questions, I'll be down here or at the IAC systems booth if you want to talk anymore. Thank you. Please leave a comment exporting this file to output. Okay. Thanks for recording me. Bye, yeah. Bye bye. Thank you and thank you very much.
and how it's descended. That's fine. Since we're of detail in here, but I don't have to go into TrueOS project. I was part of the PCBSD project itself, but we change a number of things. And so older brother, it's not me. And he started in release, and the original version of PCBSD was then in the end of 2015, very beginning of 2016, even though something was brand new for us to the consumer of FreeBSD releases just using whatever into a few more of the differences now of what's different now in TruOS compared to FreeBSD providing as a project our own release is one of the other big changes that we have been over to this. This is one of the things that we that in, that will be dealt with instantly. Now, different packages within the base package repo. the organization of the project a bit. The project trident, we're planning on only having but then there's a few people that are also lot more of those decisions. I'm just one of the using the two libraries that run the final