 is achieving tons and tons of terabytes of features, making web services with them in the public area. So I'm almost not doing BSD at work. I've been an open BSD developer since 10 years. Maybe it will be 10 years in next week or something like this. It's been a while. I've been contributing to Mozilla since 2010, 11, more or less six years. And I've also been contributing, developing, helping the CIS admin part of the XFC project since 2006. So as a result, of course, I'm the XFC port maintainer since forever. That's how I got my commit bit in open BSD. And I've been the Mozilla port maintainer by accident since six years. So for a start, you can use open BSD as a desktop laptop writing system. It just works. You just use current, you use binary packages. You have all the desktops you want. You have the full blown desktops, the bloated desktops, and everything. You use the one you want. If you want a small window manager, you can use one. Don't worry about that. You have everything from browsers to multimedia from games, working, suspend and resume. So it's a perfect fit for dock footing if you just use to update your machines. And when something breaks, you know how to fix it. Speaking a bit wider about Firefox itself, it's been for me the leading web browser in open source software communities for a decade and more. I think I started using it when it was called Phoenix, then Firebird, then Firefox when I was a student. That's not only Firefox. There's also Thunderbird, CMonkey, which is the following of the original Mozilla suite. There was technology, which was called Zalrunner. There's a huge community compared to the BSD communities. We know it's something, I would say, 10 times bigger in terms of contributors, in terms of engagement in conferences, people trying to do some net neutrality politics. There's much more than just the code and the project itself. It's, of course, also a huge infrastructure. Mozilla used to run all its infrastructure in its own data centers. It's now moving more and more to the cloud for business reasons, for cost reasons. As a consequence, at some point, the Mozilla Foundation gave, well, they were trying to get rid of shitloads of Mac Minis that were used for building test infrastructure. So we got something like 50 Mac Minis in San Francisco. And it's been a funny, funny pair of weeks to be able to distribute all of them to developers in OpenBSD who wanted to have a Mac Minis for development. So you can see that communities can communicate easily if you know the right persons, if you are involved in both communities. It's also a huge code base. It's frigging insane in terms of lines of code. It's probably 10 times an operating system, I would say. It's a fucking maze. I don't know the code itself. Honestly, I'm not good at coding. I'm not good at coding at all. I could say I'm good at fixing bugs and finding where it breaks and how do you manage to build stuff. That's the part where I could say I'm good at. They use Mercurial. Lots of small, let's say, site projects are developed outside Mercurial. And they now have more and more stuff in GitHub. So there are lots of techniques to import stuff from GitHub to Mercurial. And you have things in both ways. And it's a full time job to keep up with that. So I count, of course. Since Firefox 4, there's what's called the Fast Release Schedule, which is modeled after what Chromium did. So it was around 2011. There's a new release every six weeks, which means there are no big features every six weeks. But you get a new real version every six weeks. And it's supposed to be totally seamless for the end user. You are not supposed to notice anything user-visible. Well, it works most of the time. The supported platforms by upstream are, of course, main platforms. Windows for like 95% of the user base. Maybe macOS for four, five, maybe 10%. I don't really know the last numbers. There are plenty of numbers on metrics.mozilla.org, I think, on the install user base, and probably like 1% to 5% for Linux. And of course, we have no idea for the others, like us. Hello. And of course, it's mostly support only on IL-386, MD64, like the platforms that people actually can buy in the market and use as laptops. ARM is support way more than before. Of course, I forgot about it. But Android is a supported platform. On ARM, on recent ARMs, like if you have a smartphone which is two years old, like this poor ship, which was 60 euros, you can't install the latest version because the instruction set of ARM has been considered as deprecated. So you need a newer smartphone. The same thing for tablets. I have a Galaxy Tab from 2011, and I can't install anything more recent than Firefox 35 or 40 something. People have been thinking it's Mozilla is dying. Yeah, it's the same thing, the BSDs are dying. Everything is dying. But there are still people working on it, lots of people. There's been two or three years during when the Mozilla Foundation developed Firefox OS, which shifted a lot of interests compared to before where they were. OK, so I'm going to yell a bit louder. I was saying that during two or three years, the Mozilla Foundation tried to develop Firefox OS on the same code base, which was full of nice ideas. In the end, the market didn't reply totally positively. So it was a fail, but they learned lots of interesting things from this. So it was a loss of money, probably. They had hired something like 600 engineers in Taiwan which had to be moved elsewhere. So for the code base itself, it has been quite a disruption for two or three years because there were shitloads of code that was called boot to gecko in code terms that could disrupt what was happening for Firefox for desktop. So it was an interesting journey, too. So yeah, the browser wars. Historically, of course, the main browser everyone, not speaking only about the BSDs, but Firefox won the browser war around 2000 something. And then Chromium arrived, and then Google poured shitloads of money into Chromium, which is fine. I won't enter into politics, but the fact that some Google applications work much nicer on Chromium because it's a main target platform because most of the people are using it don't help the other browsers. And you can think that right now, in 2017, I think Firefox has a market share of 15% to 20%. Let's say when it was around 40%, 50%, 5% or 6 years ago. In the end, it all matters. The choice you want to do as a user, if you care about having sane defaults, if you care about the politics behind what Mozilla is doing, behind what Chromium is doing with your user data, it depends who you trust. If you are trusting more Mozilla or Google, if you trust nobody, then, well, you can use links or net surf. There are plenty of choices. You don't have to use them. But if you want to do some serious full-blown JavaScript applications, you don't really have the choice. And it's a matter of habits. Lots of people have been putting graphs about, yeah, Chromium consumes less, Firefox consumes less resources. Honestly, it's only metrics. And it really depends on lots of factors that I have no idea. You can use the numbers the way you want. In the end, it all matters. You can just use the one you want. So back to 2010, we ran on OpenBSG 4.6. There was a complicated transition between Firefox 3 and Firefox 3.5 and 3.6, and Firefox 4 was coming. And the current maintainer wasn't replying to my emails about updating them. He wasn't very responsive at that time. He, I think, he didn't have much time. So I started looking at an interesting challenge. OK, I can maybe update to Firefox 4 as I got interested in the new fast schedule. Fast release schedule looks interesting. And it got me into the rabbit hole for the years since then. At that time, Firefox was working perfectly fine on Mac, PPC, and Spark 64. It was building too on alpha. I don't remember if I ran it on alpha on a console screen, like the real glass screen. You could see that the code base was aged. It was working, but GMAG and Ontol everywhere. So that's, yeah, OK, people think it's horrible. But still, we know how to understand it and hack it. That was not so bad. We were able to build it with a system tool chain, which was at that time probably GCC4 and GCC3 on some platforms. But we had to use GCC4 because it was C++ from 2010, which was requiring some stuff which were un-present in GCC3. There was Java plug-in, of course, coming from the Ontol GDK 1.5. There were lots of other plugins, NPAPI, which is the way Gecko Engine allows plug-ins to interact with the browsers. For Java, for having a terminal in a tab, which is funny, quite useless. For media playing outside of the browser, there was Gecko media plug-in. In the port, there was something that I'm only talking about Firefox because there was more or less the same thing in CMonkey and Thunderbird. There was around 80 to 100 patches for lots of things without comments, without I only had the CVS log, honestly. Xol itself was the toolkit Mozilla was promoting to build the graphical interface of the browser, everything which is outside the browser window, well, I mean the web page was built around Xol and XolRunner was the runtime to be able to build applications using these toolkits. It was still used a lot in 2010 and of course there was Thunderbird 2, CMonkey 1.7 something which was more or less the Mozilla suite still building but without new features for people who are used to the old interface. It's still available, of course. In 2013, after three years of nice work, I managed to remove, well, to upstream all the patches. Most of the patches we had, I got involved in the Mozilla community to build the ports, everything which was common was centralized in a module for the ports tree which allowed me to do lots of cleanup and only have the important thing for Firefox and Thunderbird separately in their own makefiles. We were already building with Selang or GCC 4.6 depending on the platforms since Firefox 6.17 because I think at that point it was requiring some features from C++ which weren't available in GCC 4.2 that we were still using in the base system. HTML video and audio was working quite nice. At that time, they had imported the LibAV Codex libraries to decode the video and audio. WebGL was working, depending on your graphical chipset and if you had openGL working, it was working quite nice. There wasn't a port for the ESR line which was created with Firefox 10, I think, because people were complaining that, okay, there's a release every six weeks but it's moving too fast and it's breaking our user flow so you need to provide a long-term support release so there was a new branch but there wasn't a port for it because I was considering in the end it wasn't that much work but I was considering it not that interesting that if you want Firefox, you just use Firefox. I don't want to maintain another separate copy of Firefox. And I think at that time in 2013 I already got to commit access at Mozilla because most of the developers, I was reporting all our patches through the bugzilla and after a while they got really pissed at me because I was keeping creating bugs and pushing back patches and in the end it was, okay, there, we'll give you your access and you'll commit your stuff which is in the end more or less what happens in the BSD communities too if you arrest the developers enough with patches. At some point, you get blamed and you get to commit access so that was interesting at that time because I had to learn Mercurial of course while coming from CVS, it was nice. Which is nice because with all the projects I've been working outside of the BSD I had to use Git, SVN, Mercurial, I think I had to use most of the VCS available and that gives you a different view on the way communities work, the tools they are using, most of it is already a lot, well, everything happens through bugzilla. If you want to change the comma somewhere you have to file a bug which can be considered tedious but at least everything is tracked and you can trace back a change to whoever did it, whoever reviewed it and why was it committed? Which is a process which is quite interesting compared to what we can be used to see in the BSDs. And right now, four years later, WebGL is still sort of working. The fact, the only issue is my laptop or work desktop or home desktop only have all graphic cards so it's not working for me but I know it's working for people who have recent hardware. JavaScript is not that fast, which can be an issue because more and more stuff are relying on JavaScript all the time. Lots of bits of the graphical interface are being written, well, they were written with XU and they are now written with JavaScript so parts of the user interface are in JavaScript so if you need an efficient JavaScript engine. WebRTC, which is the technology behind interpersonal communications, audio, video communications like Skype but in your browser. The code which is in Mozilla is shared with Chromium more or less and when it was imported in Mozilla it was quite funny while of patching figure out the build system which wasn't at all the Mozilla build system which was integrated partly in the Mozilla build system but still using the GIP or that I didn't really want to know how it works, that was quite painful. But right now, I haven't tested it since maybe a year, but you can use, you can try using WebRTC on Firefox, on OpenBSD, you can try, there are lots of websites using this technology, you can share your microphone with it, you can share your webcam with it, it might work but don't trust me on this. You can enable the multi-process feature of Firefox which is something that has been asked for a long time by users because Chromium added it and it allowed them to separate resources from the content process, from the UI process. Mozilla tried to develop this for Firefox 4 and then totally gave up because they had imported the inter-process communication framework from Chromium and it was totally abandoned after a while and it became something that there was more interest in it maybe one or two years ago, again. So it's working on OpenBSD, you can have it, you can check if it's working for you by going to about support and you have some line which says multi-process windows enabled or not or disabled by default or you can force enable it. I still have to figure out what needs to be done so that it's enabled by default without doing anything because most of the time it's enabled by default only on the tested platforms. We are not a tested platform of course. In the port street right now we have what I call the mainline Firefox which is 55.0.3. 56 is around the corner. It will be released like next Tuesday or Wednesday. So it's at ARC3. There's a port for Firefox ESR which is right now 52. 57 will be released in November which will be a bit too late for OpenBSD 6.2 so I'll come back a bit on that later. An external contributor made a port for the Tor browser bundle which is a modified version of ESR. Build bundling Tor and some Firefox extensions to use HTTPS everywhere. North Script is enabled by default and everything is integrated correctly in the modified Firefox version so you can use the Tor browser bundle on OpenBSD. It should work straight. It should work without doing anything. I was a bit reluctant to import it because as a Mozilla contributor in some years I've often considered the Tor browser developers as a nostile fork because they didn't try that much to contribute back all the security and privacy patches they were doing in Tor browser bundle. It was the case two years ago because the Tor browser developers themselves considered themselves way smarter than the Mozilla developers. I'm not smart enough to understand all the details but I know it improved a lot in the last year because right now the Tor browser developers are feeding back way more patches than before upstream so in the end the things really improved and I think we imported the port last year and the OpenBSD contributor we did this port spent lots of hours and bills and he was always pushing the port and after a while he spent so much time working on this. I can't let this port outside of the port tree just to reward him of all the work he spent on it for like he's been working on the port two years outside of the port tree which is an insane dedication. Xol itself, so the toolkit which was used to create the graphical interface is more or less dead. I removed the Xol owner port one month ago. It was a good moment because it was Xol owner 24 which was unmaintained for like maybe four or five years. Thunderbird itself is still alive. Sadly it got cut off the Mozilla Foundation. They are trying to get rid of the community which is developing Thunderbird because they are saying it prevents Firefox from some innovations so the Thunderbird developers which are not that much are trying to struggle to keep up with Firefox ESR. After all in 2017 there are less and less people using full-blown mail client. Lots of people are using webmails. So is it a good thing? Is it a bad thing? I don't really know but Thunderbird is still alive. I'm using it at work. The NP API part of the Gecko engine is disappearing. It will be removed in Firefox 57 to let place to what's called web extensions which is something which should be shared with Chromium which changes the way plugins are allowed to modify the interface and it's meant as preventing let's say security issues coming from the plugins. Everything is separated in a different process and the web extension doesn't have access to lots of internal workings of the browser which led to several security issues in the past. So lots of people have been complaining about that because lots of previous extensions add-ons aren't ported to the new web extension framework so lots of people are complaining, okay I'm going to stop using Firefox because this extension won't work in Firefox 57. It's a matter of time for the add-on developers to port their code. Most of the mainly used add-ons are ported to the new framework so it works for most of the cases but there are always people who are complaining about lots of things. And of course right now Firefox on OpenBSD only runs on MD64 and it struggles on I386. I still have a net-home net-book with one gigabyte of RAM which is eight years old. I can start Firefox on it. And that's very sad because I used, I've only used Firefox on all my machines and seeing it struggle I think before seeing a window it's like 30 seconds maybe one minute. Once it started it sort of works but you don't want to run full-blown JavaScript. You don't go to Google Maps. Only if you like pain. And it's a sad state. I gave up on the other platforms, more on that later. And now for the build parts. So as we only have two supported platforms on OpenBSD I can build everything with Selang. We have Selang in the base system but we are using the base system compiler on MD64 and I think it's Selang from ports on I386. The GMEK auto conf auto make auto hell build system which was working fine. But working fine to my standards for Mozilla it wasn't good enough because they couldn't parallelize lots of parts of the build system. So it was replaced by their on-grown build system. Is the good thing? Is the bad thing? I don't really know. The guys who are developing Mesh which is a do in German. And the most build which is the equivalent of the guys who are developing it are really, really smart guys. So I read lots of blog posts from them about all the IDs behind this system. I'm not smart enough to understand lots of things. But as a port maintainer it's okay. I just have to learn a different build system. Why not? I've seen a lot of Python build system. I won't mention them because I'm going to get crazy. But this one is also written in Python and it's not so bad. The most build files are more or less declarative and it's not that bad. Firefox art depends on the Rust language since Firefox 53, I'll come back to Rust later. We switched to GTK3 for OpenBSD6.1. I think it was more or less at the same time that upstream decided to switch from GTK2 to GTK3. I think we were the first one to enable it by default in the Linux BSD distributions. I had been using it for some releases before it's been made default upstream. It was working not that bad and lots of people wanted to get rid of the GTK2 parts. It predates on ICU for the internalization parts and sometimes you can build with the system-wired ICU. Sometimes you have to build the bundled ICU. Same thing for unspelling. Sometimes the version you have in the port 3 is enough. Sometimes you need to use the version which is in the source 3 of Firefox. Firefox of course bundles SQLite 3. So sometimes you can use the system-wired one. Sometimes you use the internal one. And NSS and NSPR which are released from the past are still used a lot and it's the same thing. They are developed by Mozilla as external projects which are imported in the Firefox 3 and of course when there's a new NSS or NSPR release the Firefox build system says, hey, I want this last NSS and NSPR version. NSS is used mostly for all the TLS, SSL, certificate stuff and NSPR was the portable library but I still don't know why it's still here because lots of people at Mozilla want to repeat for lots of reasons. I think it's been developed since 20 years. It's still a struggle. I had funny issues with Rust code because of course there's more and more Rust code in Gecko Engine and Rust is working on OpenBSD on i386 but sometimes with default options it blows up when building. So of course on i386 you only add three gigabytes of memory or something so it leads to funny issues. The JIT Engine is sort of funny too because they want to have their own memory management so at start I think it was around Firefox 54 something the JavaScript Engine allocates one gigabyte of memory. That's all and then does its own memory management inside it which is quite funny when you have all the security measures provided by the operating system memory management that you don't want to use because you are smarter than the operating system. I'm not sure it's always a wise idea and of course on OpenBSD as a default user you can only allocate 70, 68 megabytes of memory for a process so you start Firefox and it blows. That happened a lot so you just have to patch it and some of the Mozilla developers working on the JavaScript Engine are very friendly about the third parties and they are open to distributions. They are very smart. I am not smart enough to explain them. Okay, we have those limits. Why are you doing this? And I'm trying to make people talk to each other and it's not that easy because often it's okay those guys are crazy, they are doing silly things. They shouldn't do this. Okay, I can tell them but I can only tell them this. I'm not able to explain them why or... So it's, I'm not able to fix that kind of thing. You can only patch it and say okay just allocate reasonable amount and then allocate more if you need more. That's most of the problems I have those days for building or for running. You get memory explosions when you run heavy JavaScript. This part in my opinion is the part where we'll have the most problems in the future the JavaScript Engine. So, am I working daily? Well, not daily on the Mozilla's. For years I've been using bare metal machines. I had an i386 and an MD64 machine, a Spark64 machine hosted at various places thanks to lots of generous donators. I think I used four, five, six, eight different machines over six years. And last year I moved to use Proxmox on a single machine. Guys from Poo in the South of France lent me a machine with 64 cores and I put open BSD and D64 on it and it was totally useless because the CPUs and the kernel were ping-ponging tasks all the time. In the end, you just put Proxmox, you have KVM VMs. I can have VMs for stable, for current, for i386 for 64 bits. And in the end, if you build on a KVM VM for Firefox, it should be around, on this machine, it should be around two hours. And if I was trying to build it on the bare metal machine, it was something about three to four hours which says a lot about multiprocess performance for open BSD. I've been using Buildbot since years. Mozilla was originally using Buildbot too for all the internal CI stuff. They are moving to something called Task Cluster which I think have been developed by Mozilla, for Mozilla to distribute tasks on the cloud, mostly AWS. Everything, of course, everything is public. You can see the links, I won't show you right now. And I'm building the Mozilla Central which is the trunk and Mozilla Beta which is the beta branch every night with the trunk. And that produces a package, not an open BSD package, that's a tarball with the binaries in it that you can just untar and run Firefox from it. And I, of course, build package, sign and distribute the released betas. Like for Firefox release, there will be something between 10 to 12 betas released every week or every three or four days. And I package them as an open BSD package and I distribute them on a separate package repository. I sign the packages so that you can know that, okay, those packages come from Landry. And that allows me to use betas on my machines so that I can dog food what's going to happen in next versions. I encourage people to use those betas after all, if it's in beta, it's not that experimental and what's in nightly which can be quite funny. And I manage the port and the different branches in git repositories outside of the port street and I only commit to the port street in the CVS when there's the released version so that I know that I've tested it enough and I can distribute it to users. And it's working quite fine since since those six or seven years. I think we have the Firefox update in the port street like in the next, in the three or four hours after it's released upstream. And of course, it often happens that you have the .0.1 and the .0.2 version released some days after the main release. So you get that into the port street that gave me lots and lots of free commits to the OpenBSD port street, of course. I try to track the CVS files in my git repository so that I can track which patches are temporary in my workflow and the ones that I will have to commit to CVS. When I started, there were lots and lots of patches. Right now, they are almost known and I'm trying hard to avoid committing patches to CVS because that means I would have failed in pushing back the patch in 12 weeks since I know every day if Nightly is building or not and I know every day if Beta is building or not which means when the build bot is red I have to go look at it and figure out if I need to fix something. So maybe let's just see one second. Okay, I don't have net, so we won't see. Forget about that. I try to explain most of this workflow and tool chain in an undeadly article. The slides will probably be available. I used to do slides in a web page and I found it funnier to do slides in a presentation in a terminal for someone working on web browsers. It says a lot. I have special uses for web browsers. What's my workflow when there's a new upstream release? I get a mail every day telling me if there's a new version. Just have one line to change the make file. Eventually adjust dependencies if something doesn't build with the version of SQLite we have in the port street or NSPR. That kind of thing. Just grab the new source table, apply patches, update patches if it's needed. Update the P list if there are new files in the package which happens almost never. Package it, upload it to my private server where the package is signed and distributed in distributed. I commit my work to my Git repo which is also public and then people can just use the beta on their laptops. They just have, if they use my package repository in their environment in the package path variable they can just update and use the new beta version. And I try to package most of them when I'm around the computer. So yeah, more on build bots. What it's doing, every day it's building and I don't have anything to do. I just have to look at it from time to time. I only follow the RSS feed from the build bot to see if it's red or green. Most of the time it's working. The trunk has been building without patches. Most of the time since 2012. And it's building the default configuration, the default upstream configuration. So when something gets enabled by default you can see that it breaks quite fast for you because everyone forgot about what wasn't in the supported platforms. It's building on OpenBSDMD64, I-36, FreeBSDMD64, Flow is providing me a BI VM for that. And I'm not doing anything on it so sometimes it works, sometimes it doesn't. I don't maintain this slave. I just have access to it to check the dependencies but other than that I'm not doing anything. It's also building most of the time on FreeBSD. And it provides what's called the Mozilla package that you can use to test for regressions if you know that some feature was working in the nightly build from yesterday and no it's not working, you can grab the different binaries. Of course on OpenBSD the binaries are dependent on the libraries that were on the system on the build slave at that moment but I try to update the build slave every time there's a new OpenBSD snapshot. So if you are using current you can use a current package of Mozilla on your OpenBSD current. I don't know of lots of people doing this but that provides everything needed to people who want to test for runtime regressions for what's the default Mozilla configuration. So now a bit more about the relationship we have with AppStream. They know we are here at least for FreeBSD and OpenBSD because we are two developers active a lot in Mozilla. Yanbei from FreeBSD has been doing a lot recently. I've been doing way less than before. I had way less time for this. So he took the job I had before of reporting your stream and stuff while I'm building. He's doing more patching than before than me. And as I've been in this community since six, seven years I know lots of the Mozilla developers. I know where they are working in which area of the code they are working. I know who to ask for hints or reviews being on the Mozilla IRC helps. I've met lots of them live in Toronto in the Mozilla office yesterday, two days ago in FOSDEM in different conferences. And it's always nice so that they know, okay, yeah. Okay, you are here, you are at the BSDs and you can put a face on the name and okay, we are going to try to be nice with you. Of course, we are not a priority platform and it was true some years ago. They knew, really knew that we were here and they were trying to ask me for feedback on patches that they knew were going to land and might possibly break us. It's a bit less true now because they've been less involved and you get lots and lots of bugs because some of the new Mozilla developers don't know that people are using Mozilla outside the tier one supported operating systems. So you often get build failure because we don't have the SPS profiler which is some feature that would have to be written from scratch for the BSDs and lots of people build write code that rely on this feature and you get a new build feature and okay, it's always the same thing. That's a bit sad. Upstream is really welcoming contributions from outside us. As long as you provide, as when you are reporting a bug to your favorite BSD, you have to provide details. I was doing this, it doesn't build since this change you need to learn a bit about all the mechanics behind the Mozilla community and the tools they are using to bisect and where to look in the code. This change broke me and I have to come back to the bug that was where the discussion happened on this change and you file a new bug that says, okay, I'm blocking this bug because since then the build on my platform is broken. After a while, you really get used to it at the beginning. It's quite hard to figure out how this community work but in the end, it's very interesting because you see the differences in the workflows between the different projects and depends a lot on the project size of course. If you are an open BSD user and you have a bug on Firefox, maybe it's not open BSD specific. Well, if it's something like memory exhaustion or it's probably open BSD specific with the limits we have but most of the time I'm not able to deal with it because I have no special knowledge in the code but I can tell you who to ask, file a bug, get involved in the community that will help me. Of course, most of the time I'm only dealing with build system issues, which is the easy part for me. So different topic, something I started this year since I moved to KVM VMs on Proxmox and that's something that's been discussed a lot in open BSD about providing updated fixed packages for the stable versions of open BSD. It's been discussed a lot. It happened for a while. It's been provided by MTR which is a separate company for a while for some packages which were mostly the server packages. And a few other, okay, but people are using, some people are using open BSD on their desktop. They want to use stable for reasons, why not? And it means that when you are using stable you are just using the version which was in the release when it was cut which means after six weeks you are not using the supported release upstream. You might be vulnerable to lots of problems. So I started working on the stable VMs to back port what's in current to the ports tree in the stable branch. And of course it's not enough because if you commit to CVS people have to build their own package. So the KVM VMs allow me to package updated versions which means that if you are using 6.1 and you use the repository pointing to the 6.1 sub directory, of course you can have Firefox 55.0.3. And when 6.1 was released with Firefox 53 something I don't really remember, maybe it was 48. And in the last months I got some users. The numbers are interesting because it shows that almost nobody is actually using I-386. It's not that much so I don't know if people are not trusting the packages I'm providing if it's too complicated to use them. I don't really know what to do about it but I think it's nicer to users to provide them stable packages so that they can directly install them on their machines instead of having to build them. And for beta packages allow me to see that some people are actually using the beta packages. So yeah, the topic about portability. I gave up on PowerPC in Spark 64 a long time ago. NetSurf is a perfectly fine browser which was developed for RISCOS which is insanely portable to lots of platforms. It works perfectly fine on PowerPC if you are still using a PowerPC laptop or Spark 64 machine. I gave up on this. Martin Newsman who is here is doing an insane job at trying to have NetBSD Spark 64 still having a working Firefox and I thank him for that because he knows lots of stuff about Spark 64. I know close to nothing about Spark 64 specifics. You have NGNS issues. You have the unaligned access in the JavaScript engine. You don't want to know about these errors. And a bit now about the future. I will try to go fast on this the five minutes. Rust is the future for Mozilla. They developed the language themselves. It has some popularity outside of Mozilla. On Stack Overflow, I think there are ISO numbers about developers using this language for lots of other things. It's taking momentum. I think it took some momentum to the Go language. Of course there are lots of new shiny languages with Elm everything. Like every new language you have to have your own package manager which is called Cargo which was a different port which is no inside Rust. The Rust port has been maintained but by Sebastien Marie who is doing an inside job at it. I thank him a lot for that because you have, of course, as a language you have to bootstrap it. So he managed to bootstrap it from Linux, MD64, two OpenBSD, MD64, going through crazy hoops and loops. As it's developed by Mozilla they are releasing a new version of the language every six weeks. And there's something called RustUp to update the language compiler itself which is, of course, an issue for OpenBSD as the binaries are provided by a third party and you can't be sure that they will run on your machine because of the library dependencies, the IBA, everything. And as Firefox, Rust language itself is supported on mostly the main platforms like Windows, Linux, ARM, Android, MacOS and OpenBSD is far from tier one. I know FreeBSD and NetBSD are tier two because they are providing RustUp binaries. Upstream is providing RustUp binaries because they are not the same ABI issues that we have on OpenBSD. And parts of the Mozilla code base are being slowly rewritten using Rust which allows Upstream to remove lots of parts of old code which is here since the 90s. There's been a recent policy about making Firefox build system depend on the recent version of Rust which can be a problem once I had the Mozilla nightly trunk failing to build because it was requiring Rust, the version of Rust which was released Upstream the last day which is a bit short to have someone update the language on your operating system. Outside of Gecko, Mozilla has been developing Cervo which was a research project to rebuild the web engine from scratch massively parallel everything in Rust. And now there's what they call the canton project which is to migrate features by features from the Cervo Engine to Gecko inside Firefox. So there are four main parts and Steelo is the CSS Engine written in Rust which is supposed to replace the CSS Engine which is in Gecko and that will happen by default for Firefox 57 which is not that far away so it means lots of testing in the coming beta cycle. And for OpenBSD, what's Firefox future on OpenBSD? As I said, I gave up totally on the other architectures I'm sorry for the ones who are using Spark 64 or PowerPC I just can't deal with that. It's too much pain I'm not smart enough to understand the specifics of the platforms. Upstream is more and more reluctant to allow you to fix the wrong engine as platforms because it's lots of changes to push back upstream. The next hurdle is to have Steelo working on I-36 because by default the Rust code in Firefox is built with all the information which of course explodes the memory limits that you have when you are building on I-36. The next problem for me will be to enable the multi-process features. It's working on OpenBSD. Right now we have one content processed by default. Upstream is planning to move to four content projects to move the network communications to a separate process to move the GPU communication to a separate process to have a local file system access in a separate process for the sake of course of security and sandboxing which means you need efficient IPC. On OpenBSD it's working. I don't know if it's efficient but sometimes you get real slowness in the browser. I need to look at sandboxing for Firefox 57. It will be toted as the version where everything is sandboxed on the main maintain major platforms. So need to catch up with that and figure out how you can pledge the different processes but first you need to have by default working and a reliable multi-process in Firefox. Need to figure out if I need to push the default limits to something bigger. I need SEM open. Recently I had to do a hack to use a Mac OS code path because some feature was relying on SEM open then for some reason we don't have shared SEMA4 on OpenBSD or I have to bribe you to write the feature in the kernel itself if it's not considered security sensitive. And yeah, of course the generally the stuff that gets enabled by default in the build gets me in trouble most of the time. I need to keep Rust working. If something happens to Sebastian and is not able to maintain Rust I'm stuck with the Firefox version that will require the Rust version I have. There's of course the Rust ABA target issues. Jean-Sébastien Dumbbell from 4BSD is working with Sebastian with that on trying to push back upstream the idea of okay you provide binaries but you need to provide binaries for different ABAs 3BSD 11, 3BSD 12 for OpenBSD we don't say that the ABA is stable for every release so that means providing binaries for every release. There's discussion in trying to have that kind of switch upon at runtime which will solve the problem for everyone but that has to be pushed back upstream. WebRTC needs testing because I think it's an interesting technology in itself allowing lots of people to use video, audio, intercommunications without relying on Skype or having Linux running something for Skype or that kind of or else. ARM64 might happen someday. I know Peter Ester was doing ARM64 package builds. We look at all that's needed to have Gecko building on ARM64 but that means you need Rust. That means you need lots of other bits but most of the code itself should be here because ARM64 is supported on Linux. Why not on OpenBSD? That's lots of ideas for the future. I have way less than I'm before. I have less motivation to be honest. So I'm still looking for help. If people want to get involved in Mozilla, in OpenBSD, I welcome help but you just need to get used to the tool chains, the different ways of building it but I think most of the stuff I'm doing is documented and public and I'm of course available for questions to the point of questions. Slow on time. Sorry. We have time for your questions. So who's interested wants to start? How did you get Mozilla folks to accept patches for OpenBSD at all? Many years ago I tried doing that and I was told we're interested in Linux, Windows, macOS and the rest of you. We don't want your patches in our repo. I think it was just a matter of opening bugs and making sure that the patch you are feeding back don't break anything of course but since it's not part of the supported architectures most of the time they don't really care because they are trained to be friendly honestly and it's just a matter of getting to have people know you that you are here and you, okay I have 100 patches and I have to feed back them but first that meant I had to understand them why they were here because if you feed back the patch you have to explain, okay I have this patch take it that doesn't work. You just have to understand why it is here so I just add the CVS log which doesn't help a lot most of the time. I removed lots of patches which actually were totally useless. I tried to remove all the patches which were customizations. I prefer having the defaults that upstream provides and try to stay away from customizations because when you report stuff upstream they prefer having the default options and configurations. It was true some years ago now since I have a bit less time sometimes it acts removing some stuff I don't like it but they are really welcoming patches. I think it all depends on the way you feed back them and you have to go through Buxila and find someone to review them so now they are welcoming, they are much more open to, well they have always been open to contributions but now they are trying to welcome new contributors and give in an easy path to feedback patches and to find the reviewer. For me it's not an issue, it's I know most of the people where in which area they are working but now they are something which is suggesting a reviewer based on the paths that are in your patch so that it's in this code area so that the people responsible for this code area are those possible reviewers. So that's part of the way of dealing with it and six years ago I think it was less people to do a lot. Actually I think the biggest problem a couple of years ago was they expected you to find out who's responsible for reviewing something and not providing any help with that part. But at that time there was only a wiki page listing people names and the code area which worked but wasn't that easy and going to IRC and SPIN people is the best way of finding the right person. No, in that case, thank you for the talk. Thank you.