 Welcome everyone to my presentation about porting Chromium to FreeBSD. Maybe a couple of words about me first. I'm Mrs. Edmund, turned consultant from Cologne, Germany, dabbling for around 20 years or so in the FreeBSD environment, at least as a user. And yeah, picked up the Chromium topic, I think, like two years ago or something. And yeah, wanted to show a bit about our struggles and what we have to do to get and keep Chromium running on FreeBSD. As of all the current state, Chromium is in FreeBSD ports since end of 2010 for version 8 or 9, I think. And since then saw various updates, more or less following the release schedule, sometimes closer, sometimes with some gaps. Currently we're quite up to date. We have Chromium version 92 in ports, actually, which is like a couple of weeks behind, unfortunately. But we are working on Chromium version 93, which is the most recent one to keep it up and going. Out of the box, for nowadays, we support most of the things Chromium brings. So as you can see, web conferencing now is working seamlessly on FreeBSD using Chromium. That's what I'm using right now. The biggest hurdle for us in terms of porting issues is the ever-growing need of more and more patches. Because there were various efforts to upstream or local patches, so that we get at least some kind of support in Chromium upstream. But the history from the past showed, I think, very decently that this is not something the Chromium project wants. At least there were explicit statements that this might indicate some kind of support, official support for the BSDs in Chromium, and that they rather would not do it for this very reason. Yeah, so we're keeping all the patches in our ports infrastructure. And yeah, this is quite a hurdle to do so. It doesn't help that the version policy of Chromium is quite fast. By default now we had a new version every six weeks. And whenever we get a new Chromium version, all of the old versions are immediately outdated. So if you want to have the most recent security patches and so on, we need to keep to the most recent Chromium version. And starting with version 94, this tends to be even more of an issue than it is right now because they're moving to a four-week schedule. So we need to be even faster in importing the latest changes over to our adapted version for free BSD. Maybe, or they parallel with the V94, they want to release on an eight-week schedule some kind of stable version. So maybe that would be a good path forward for our port so that we can maybe reduce a bit the time that is required to keep Chromium up and running. On the patches side, this is what I mentioned before. Currently we have nearly 1,000 patches for the Chromium tree to make it running on free BSD, which we need to maintain, which each new version because they tend to refactor a lot in the code. So at least a good portion of the patches will fail to apply whenever we import a new version into the ports. Luckily for us, most of the patches are really just applying the fine to the Linux-specific section that we want to compile them on the BSDs as well. But we have quite a lot of operating system-specific stuff we need to maintain and keep working in the free BSD land. Most of the stuff, which is specific only for free BSD, is we handle everything that is specific to process handles and process metrics that we have somewhere in Chromium, which has its own free BSD implementation classes as well as any system information and any human interface device connections that Chromium tends to do by itself as well. On the audio side, luckily the OpenBSD guys have an implementation for SNDIO, which we adopted to our port so that we get that stuff as well. So all in all, when patching a new version or importing a new version of Chromium, usually we do it in a couple of playthroughs. So the first one is to try to get all of the existing patches working again, at least that they apply cleanly. And then we need to come through all of the code that is changed to see whether some of the Linux-specific code needs to be enabled using the Defines or even needs to be adapted because they do some Linux-specific stuff, which we need to write an implementation for free BSD for. And currently, when compiling Chromium, it's about, I think, 50k C++ fire, at least the web renderer, the blink stuff, heavily templated. So it may take quite a while to compile the entire beast. I think at least on my machine it's without CC cache per day or so. So we try to start early on the patch cycle for each and every new version so that we, on release day, might have something working. Obviously, we don't succeed all the time on this, but this is at least the goal we do have for the port. Other things, Chromium by itself tends to depend on quite a lot of third-party stuff, which by default they use fixed-entry versions of it, which is, I think, good for the Chromium developers because they have a fixed version that can target, which is a bit problematic for us. Sometimes we need to patch those libraries as well, because we have them living separately in our ports, and not all of the patches are upstreamed there as well, or they have just some old versions, which don't have the free BSD patches yet. So what we usually try to do is to change the build mechanism to say that we don't use the entry versions and rather rely on whatever is installed on your free BSD machine and depend on the versions from ports, so we don't need to care as much about porting those third-party to Chromium at least, libraries as well. It doesn't work all the time because at least for some libraries there is some kind of tooling to do this, but at least we have had a couple of versions where the release build didn't work when we did run the Unbundler to use the system libraries. I think mainly because none of the official Chromium releases uses that tooling actively, so while it tends to get fixed, it might be in a broken state and down then. Another big issue, at least, I think to nearly every distributor of Chromium is the whole Python issue. I think most of you know that Python 2.7 is the end of life for some time now, and on the one hand we have very good news, at least since version 92 from August, I think. The default version we need in the build system is now Python 3, but there are still parts of the build which fall back and require Python 2.7 interpreter to run. So now we don't depend purely on Python 2 anymore, but now we depend on both Python versions, which is I think a step in the right direction, but it's not where we want to be. So at this point in time Chromium is still one of the offenders in the parts tree that we I think really don't want to remove, but it's keeping us from removing Python 2, because we still need it for building Chromium on a side note there. Chromium depends on a lot of stuff to build actually, and currently they use their own make file generator, which is called GN, which is Intree as well, which then goes on to generate Ninja build files to do the bulk of the build using Ninja. And then calls various tools from that. Most of the scripting is done in Python, so that's where this Python issue comes in. But we also have dependencies for example to Node.js, because some of the stuff, the JavaScript stuff in the browser depends on Node. And we used to have dependency to Java for a couple of time, because they had a couple of tools to optimize source files in JavaScript, which was written in Java, so they called some Java stuff during the build. So one gigantic ecosystem of stuff that we need to build this and to keep this running. Another interesting point is, which I did a lot of, or at least some kind of work in the past, I think half year, is Capsicum for multiple reasons. One of the reasons obviously is, web browser is like such a central component, which is very exposed, because obviously we do a lot of external connections to it, that we really do want to have sandboxing in it. Luckily for us, there already was a PUC for Capsicum and Chromium. The not so good news is, this was in Chromium 8 and 9, so a lot of things have changed since then. What really helps for us there is Chromium is already built with sandboxing in mind, and they do ship a pliothoror of sandboxing mechanisms specific for each and every operating system. They at least officially support. Currently we are back to the state again, where we at least have the tooling in place that we call or custom FreeBSD sandbox implementation inside Chromium, but it doesn't really do anything. But it should make it easier for up and coming versions to re-enable Capsicum at least for some of these sub-processes, like Renderer or something, that we have in Chromium. So stay tuned, I think in at least a couple of months we might have something in there to further improve the security of running Chromium on FreeBSD. Kind of brings us to the wish list really, we at least I have for our Chromium port. I think the most important thing really is to add proper Capsicum support that we do have sandboxing for the Chromium web browser. Which is most likely one of the bigger issues, or at least more time consuming, because we need to test all the different code paths that it might be using. Because browsers nowadays are much, much more than just displaying a web page. There's many, many things to test really. Another thing which I think will help during porting and ensuring that no one has nasty surprises when updating to a newer version is that we should fix all the unit tests that Chromium ships with. Many of them already run out of the box, but I tend to skip some or most of them during the version upgrades. Because they add a considerable amount of additional patches that we need to take care of. But on the other hand, if we automatically can test that most of the internal Chromium stuff is working, maybe this will ensure that we have a better quality of the port itself. Next thing on the list is currently for FreeBSD we only support XTROC as a Windows Server with the up and coming Wayland. And we have at least some working Wayland stuff now in the ports. I think it should be good if we could enable the existing Wayland support that there is already for Linux and Chromium. So that we at least can play around with that and see whether that does any good and works for us. It's kind of a lower priority right now because the default as far as I know for Linux for Chromium is still X11. But it would be good to have it just in case that we are prepared for what's up and coming. And last point at least on the slide with a bit more esoteric functions, namely WebUSB and WebBluetooth, which we currently don't support at all in our port type Bluetooth stack is disabled. And I think would be kind of nice to have those features on FreeBSD as well. But seeing as our Bluetooth stack isn't really in the best shape and at least currently didn't see any active requests for having that feature on FreeBSD. It's kind of the lowest priority, but we have a couple of things that we can work and that we can enable if we have too much time. And lastly, the main repository where we do development for a Chromium port is nowadays on GitHub and the Chromium repository and the FreeBSD group project. And yeah, this is where we have all the development for new versions in their branches and have the master sources for the port. And we have for FreeBSD-Chromium mailing lists, which at least we or I kind of actively read. So if anyone has good ideas or wants to help on that, feel free to use any of those resources. And lastly, I wanted to thank on FreeBSD side Rene, which is currently taking care of most of the testing and bringing everything into the port street. So I'm only developing the port and putting it up to GitHub and everything else. This is his work and Robert from OpenBSD, who is maintaining their port and is responsible for example the sound IO implementation. And this is one of the resources we kind of use if we're stuck and some problems which we have in the port. So yeah, then I think that's everything so far from my side. So we can take a couple of questions if you want to. No, there are some questions in the chat. Yes. Do those first. If people can do questions with voice, they can just raise their hand. That's the raise hand button in the lower right corner. I can unmute you. I can talk or speak. So I think the first question from the chat was no chance of getting that integrated upstream. Honestly, I think we don't have any chances to actively get anything upstream. We have a couple of places interestingly. There is I think in the policy stuff section where they enumerate operating systems and have assigned constants to it. And in some version FreeBSD just showed up with a comment on, hey, we've put some unsupported platforms in there to make porting easier. But on the other hand, at least the most recent tries to get anything integrated upstream were rejected due to unsupported operating system. So maybe in a year or so it would be a good call to maybe try again. That could have changed, but I don't really see any chance right now to get anything in there. Next question. Which parts of Chromium are the biggest problems with porting FreeBSD? Specifically, would it be possible to take parts of Chromium and completely rewrite the parts that are Linux specific? We kind of do this already. But it doesn't really help all that much because I think the Chromium authors are quite eager at refactoring. They're called from time to time. So we need to revisit the places we rewritten for FreeBSD periodically as well. At least that we adhere to the newest interfaces and things they shuffle around in the base library. So right now it seems to be the easier approach to everything that is Linux specific code which works on FreeBSD kind of to just enable and use that. And just stuff that we don't or can't use rewriting that. A couple of things we also take from the Mac port like the KQ stuff or so. So yeah. Next question I think is whether we have any specific wishes or features of feature request for the base system? I don't think so at the moment because most of the stuff that is Linux specific is I think nothing we want to have in base. Like Chromium does fancy stuff like reading the procfs files directly and extracting information from there. The entire Bluetooth stack which is Linux specific as well. Other than that I don't think we have anything in there which really would be urgent for us to have at the moment. Any further questions? How much effort is porting an updated FreeBSD usually? It depends whether we take time actively spent developing or time waiting for the compiler to give any meaningful results. I'd say the usually all the porting stuff that we actively do can be done within a day. If there's not like some new subsystem or any bigger issue within the within the build system. So just the default nothing much has changed thingy. Which then usually at least on my side pans out over week because needing to wait for the compiler to compile all the stuff. And if I leave it running overnight usually it compiles like 10 files and then throws an arrow which I see in the morning. And I think the testing release is what is taking a long time. So usually before release we do a port area build for at least 13, 12.2, 11.4 on AMD64 and at least one of them for 386. So at least four full builds of Chromium. Which take them quite some time like two or three days. So thanks everybody for tuning in hope that it was interesting to see a bit or hear a bit about the Chromium port. And have a nice day and enjoy the other talks.