 How long has SGI not been around? There is no modern hardware system that is simple, understandable, but also powerful. And it is understandable from top to bottom. I don't know about you, but many years ago when I... They essentially forked UNIX in the early 70s, about 1973-74. The NetBeasty system today is a direct descendant of that line of development. On the other hand, you have modern features. The first thing you'll notice if you boot it on your laptop is that it will boot not into text mode, but into a graphical console using the full resolution of your display. And that graphical console is accelerated. So NetBeasty these days has well-working graphics drivers for things such as NVIDIA cards, Intel integrated graphics, whatnot. And so even your text console has these. You have ZFS, which is a big deal. It's a new feature in NetBeasty 9. It has a few limitations. It's not quite as powerful as in FreeBeasty, but you have ZFS. You can have LVM, the logical volume manager. So you have flexible ways of defining your storage and you have a bunch of other server features. If you want to use it as a server, that's good. You have support for a lot of programming languages, like Go, for example, supports NetBeasty. Well, Maya just did a talk in the Go dev room about porting it to more architectures. There's CC++, obviously. Ruby, Python, Perl, Raku. You name it, OCaml. It's all there. And it also makes a surprisingly useful desktop OS these days. You have a bunch of desktop environments such as Mate and XFCE available. You have browsers such as Firefox and Midori. You have like Gimp and LibreOffice. It's all kind of there. And with the graphics acceleration, you can install Firefox. You can go to YouTube, YouTube works. That was not the case a few years ago. Here's an example for a desktop usage. Somebody from Japan running NetBeasty on a laptop with an internal digitizer display and just drawing casually on it. Also, NetBeasty is kind of, I feel, one of the systems that's most at home in the cloud. First of all, there's at least three different hypervisors. There are now, on the system, you have Xen, which has been there for a long time. And it's really kind of enterprise grade. You can, so on Xen, you run your main machine. The main machine is called the DOM zero. And then you can run guest domains in it. And for example, running NetBeasty, running Windows, running whatever you want. That works. There is a new hypervisor in NetBeasty 9 called NVMM that is very intriguing. It's a tiny library and a tiny kernel module. It's very elegant in how it's written. And it also was written in a few weeks time, apparently. And it's kind of similar to KVM and Linux. Essentially, it provides you, the way it's implemented now, it provides you with an accelerated QMU. So you can run your guest in regular QMU and set the accelerator to NVMM and you get native-like speeds. There's another hypervisor called Hexim. It also plugs into QMU. That's a sort of multi-platform thing. And it's used, for example, in Android Studio to run, to power the Android emulator. So that also works on NetBeasty these days. Then if you want to run NetBeasty in the cloud, we have official images for AWS, AMIs for both Intel platform and ARM platform, 32-bit, 64-bit. The ARM ones are fairly intriguing also but the ARM offerings from AWS are cheaper and faster. So that's something to keep in mind. There's other cloud providers where it also works. There's some people are using Vulture, some people are using Scaleway, which also has cheap and high-performance ARM stuff. It's all there. For Google Compute Engine, we have the staging script here that works well. And finally, I think what I would like to emphasize is it's also an OS that has a fairly welcoming community. This is a picture from the package source con 2019 in Cambridge. It's sort of the group picture about half of the people there are developers, I think. And I think there's been some sort of generational change in the NetBeasty project over the last few years. It used to be a bunch of sort of gray beards, if you will, like a bunch of old-school Unix types. And nowadays, there's been a strong influx of younger people. And as a result, the system has modernized quite a bit, which is nice. So it's a community that is living and that renews itself. And yeah, I like it a lot. Then I think maybe my favorite point, my favorite thing about NetBeasty is the package tree. It's called package source, written PKG SRC. And it has more than 20,000 packages, plus if you count the work in progress ones, that's another four and a half thousand. And package source cannot be used just on NetBeasty. It supports about 18 different OSes and architecture. So whether you run a Mac laptop, a Chromebook, a Linux server, you can use package source on all of these, which is really cool. And the way it works for a user is that there are quarterly stable branches. The last one is called 2019 Q4, because it was released at the end of the fourth quarter 2019. And so these remain stable for three months. And during those three months, when there are security updates or build fixes or things like that, they're pulled up into the stable tree. Then there are like build bots that build binary packages for certain architectures from this branch. And they run in a loop. So every time there's like a security update, all the stuff gets rebuilt. That depends on it. And you can use a package manager called package in. It's sort of like apt get in a way to keep your system up to date really easily. However, if there are no binary packages, for example, you're, I don't know, using the latest current or on a weird architecture of some sort, like on your VEX or whatever. It's no problem. You can easily build stuff from source. Here's an example. If you want to build Firefox, which might take a while in your VEX, you just change into the directory for this particular package and type make package install. And it'll automatically do whatever is necessary, like find out what the dependencies are that need to be installed first, download the source code, build it, build a package, install the package and so on until something fails or you have a working Firefox. If you're using that, like if you don't, if you're not depending on binary packages, but using building stuff from source, there's a tool called package rolling replace. That's kind of useful whenever you do an update of your package source tree, like say updating to a new quarterly release or something like that. You just run package rolling release dash U, like update, and then it'll automatically find out what packages you have installed are outdated compared to what's in the repository, and then rebuild them in the correct order. So like the things that are lower in the dependency tree come first. So you can do that once. It'll also take a while, and then you have up-to-date packages. It's really nice. Compared to if you add ZFS in the mix, if you have your package directory under ZFS, you can do a snapshot before you start and if you're scared that things might go horribly wrong, if they do, you can just roll back that snapshot. It's really nice. Also, I found that package source is one of the easiest ways of actually creating your own package. There's a tool called URLToPackage where you give it a download URL to the source and it'll start building a skeleton for you and then you just fill out stuff. It's really easy, and there's sort of a gateway drug to becoming a package source developer. There's a staging repository called package source whip work in progress. It's really easy to get an account for that. You don't have to become like fully a NetBSD developer or anything like that. You just send a mail to the owner of this repository and attach a public SH key and then you're in, more or less. So package source whip is several things. It's kind of a testbed. It is, if you're a contributor, but you're not a developer, it's a way you can put, say, a package that you make changes to. You just commit it into whip and it's a lot easier than attaching a patch to a mail or something like that because you can actually review it. Some people, like, when they start working on a new package and they realize, like, I won't finish this today. This is not building correctly or something. They still commit what they have into whip and then others can continue on that. It's also, like, it's really good. As a user, you should know the packages that are in there might be slightly broken. Typically, there's a to-do file if they are and so if there's a to-do file, you should read that before you install it. Anyway. And now I want to take a little break and do a tiny retrospective on my talk from last year. If you remember that, that was called an update on NetBSD. It's kind of similar to this one. And back then, I was actually talking about NetBSD 8, which was the all-new release back then. And NetBSD 8 is now stable and 9 is coming up. It took over a year from the time when the NetBSD 8 branch was cut from the development branch to the release of NetBSD 8.0. And it was kind of a long time and a lot of people were kind of nervous about it. And I realized when preparing this talk that it's almost as long already for NetBSD 9, but I think we're really, really close. Unfortunately, it's not there yet. So the branch from the development tree at the end of July 2019, you might remember that the middle of July 2019 was when 8 was released. Basically, as soon as we were, as we got rid of one better branch, we created another. And I think the same is going to happen after 9 is done. And I actually asked Martin Husserman, who is the release manager for NetBSD, if I could announce this release at Fostam, if we would have a release. And he was like, no. However, there's a release candidate number two that he promised me would be released now. It is also not really... But it should be any day now. So there's a release candidate one that is from late November and release candidate two is coming because there were some bugs fixed since then. And I think if I were you, if I were starting with NetBSD, I would start with NetBSD 9, whatever state it is in at that point. As I said, ZFS and NVMM are sort of the big new headline features. I talked about the accelerated graphics drivers earlier. There was a big update to those. So if your graphics card is less than three years old, then you may want to install this. And then in terms of the hardware support, there's a lot of improvements in the ARM architecture. It's called EVB ARM evaluation boards with ARM architecture, but it's really all sorts of things, including laptops and stuff. In particular, EVB ARM now has 64-bit support. So on a Raspberry Pi, for example, you can install it in 64-bit mode and you get a bit more performance. It's really nice. For developers, you have a bunch of sanitizers, both in the kernel and in the user land. So you can run your code against UBSAN and ASAN and TSAN and whatever their names are and find bugs. There have been a bunch of bugs found in NetBSD itself, obviously, and fixed. There have been a bunch of security improvements. Our security folks are particularly proud of this thing called kernel ASLR, which does full randomization of all the kernel addresses to make exploit development more difficult. And it does that by adding another stage between the bootloader and the kernel. So it loads something called a pre-kernel that'll load the actual kernel, rejigger all the stuff, and then start it. So that's kind of nice. And now, you know, maybe I have convinced you now that NetBSD is a cool operating system, so I want to address the question like, what are you going to run it on? Of course, you could run it on the laptop you already have or the desktop you already have, which is probably an AMD64, I guess, like a 64-bit Intel or AMD CPU. But there's also more interesting machines. Most of them incidentally running ARM. So here's one that you probably all know, the Raspberry Pi, $35. Reasonable performance, doesn't blow anyone away really. And you have wireless LAN, you have Bluetooth, you have a bunch of extension thingies you can install, I don't know, LEDs on the bus. It's a cool hacker toy. You know, why not buy one of these and use NetBSD on it? You may wonder why I showed the Raspberry Pi 3 and not the 4, which is because the 4 doesn't quite work out of the box. So there is this thing here. You have to download an image and then untar this file on top of the FAT partition for people who are looking into the, like, this is more for reference if you're looking into how to get it working. But the Raspberry Pi 4 works with this. Here's another one that I'm very excited about and a lot of other people as well, I think. The Pinebook Pro. I think they might have a presence here at FOSSTEM. They might have a stand outside. The Pinebook Pro is a laptop running an ARM processor and it is $199. So it's really cheap, but it is really high quality as well. Its predecessor, the Pinebook without the Pro, it's more like a netbook if you remember those. But this one here is like superb keyboard, great build quality. It's really a notebook that doesn't have to hide behind the Apple stuff or whatever. It's $200 and it will run NetPCD natively. So here's one of our developers, Jared McNeil, who are making some publicity for this. So you see display, backlight control, SD card, NVMe, USB Wi-Fi audio, and I don't know what DVFS is, are all supported. So you can download an image there on armbsd.org or on the NetPCD site and just write it onto a SD card, put it in the Pinebook Pro. Superb. And that's really all I have. Thank you very much. Do you have any questions? Yes. What is the minimum amount of RAM you need to run ZFS decently? The minimum amount of RAM for ZFS. I think technically it's one gigabyte, but if you have less than four, you might not be super happy with it. Yes? Does this support hardware acceleration or the Pinebook Pro? Hardware acceleration on the Pinebook Pro. I'm not sure. I don't think it does. Yes? What would you say is the performance of that new hypervisor compared to older ones, especially compared to Beehive? What is the performance of NVMM compared to Beehive? Maybe the question should be why didn't you... Why does it not Beehive? I think the reason why it's not Beehive is that it was easier writing this from scratch than porting Beehive. And it's really very minimal. I don't have any performance data compared to Beehive. I don't know. So as far as I know, Beehive is free BST only. Is that correct? Andy Lumos. So the question was what is the glue language of package source, saying OpenBSA has a lot of Perl, FreeBSA has a lot of Lua. Package source is a lot of make. Like the main control file for a package is a make file. Behind the scenes there are a bunch of scripts that are AUK and Z and so on, and a few C programs. For example, we have wrappers around the C compiler and around the linker and all of that, and they're written in C, so you don't lose too much performance. That way, even if a build system is behaving badly, we can be sure that the arguments we really want to be there are sort of injected into the command line. That's what the wrappers do. Any more? Yes? Can you do GPAU pass-through? I don't think you can. I think the display is always emulated. You might be able to do it with Xen, but it's hard to get right, I think. But you might be. Yes? All of them, really. It's as generic as KVM, and because you have QMU, you get emulated devices for things like network, or if the guest OS has proper guest support, you will get non-emulated devices. All right, thank you very much.