a stitch in time: jhbuild
Lortie, Ryan
BSD porters have always struggled with portability of software written by Linux users and never tested elsewhere. GNOME has been particularly difficult. New releases would come with new headaches, every six months. By the time the issues were addressed and fixed upstream, a new release would be out with new issues. In 2014, the FreeBSD GNOME Project changed their approach. jhbuild is now building the full GNOME stack on FreeBSD systems, at least twice daily, directly out of upstream git master. When portability issues creep in, they are addressed immediately  often with patches going upstream the same day. When it comes time to build ports from release tarballs, there are no surprises. A direct result of this effort has been two on-time releases of GNOME (3.12 and 3.14) in FreeBSD and GNOME 3 finally landing in the official ports collection. This talk will discuss what was done and how it changed the relationship of the FreeBSD and GNOME projects as well as discussing important issues going forward.
 Can you just introduce yourself? Oh, yeah. OK. So I'm Ryan Lorti. I'm a member of the GNOME project for a long time. And a small while ago undertook improving the relationships of GNOME and FreeBSD. So yeah, I guess that's the introduction, in fact. So I noticed that there were two big problems. And I was sort of approaching it from the problem that GNOME had. But there was also a problem in FreeBSD, which was that GNOME on FreeBSD was not happy. There was version two in the ports. Like version three came out. And it was many, many years. And there was still version two in there. And it was kind of a bad situation, because GNOME is big and unwieldy, and it tends to touch a lot of things. And every time a new version came out, it would be like, OK, what's broken now? OK, well, everything's broken. So we've got to file a bunch of bugs, get it fixed upstream. Hopefully, it'll be fixed in the next version. OK, great, it's fixed. But now a whole bunch of other stuff is broken. And this was just because if you're doing something only once every six months or even sometimes longer, it's not fast enough to catch the problems as they're happening. On the other side, I maintain G-Lib, which is sort of like the base library of GNOME. And it's kind of a mess when it comes to portability. We have so much stacks of if def code around certain things like stat and stat VFS and stat FS. And just basic stuff like, how do I figure out how many free blocks there are in this file system? There are about eight different ways of doing this, depending on the operating system you're on, like old versions of Solaris and stuff. I don't even know how much of that code we use. This is a problem for me, because I kind of want to rip it out. And I'm kind of wondering, well, if I rip it out, is somebody going to get angry at me? Am I going to get hate mail? I don't know. So wouldn't it be nice if we had an actual set of supported systems that we knew that we supported, and we had a way of testing those systems? So we sort of decided in G-Lib. And if G-Lib does something and says, this is the way it is, it's pretty much affecting all of GNOME, because you need G-Lib to run GNOME. So we said, we're going to move away from this idea that we theoretically support anyone who wants to come to us. And we're going to try and nail down more concretely. An idea of we support these platforms, because we care about them, and we know we support them because we actually tested it. It's not just theoretical, hey, somebody sent me a patch a long time ago. Maybe it's still working. It's something that we're testing regularly. So we have a list of platforms that we actually target. And we actually do test regularly on most of them. And we've gotten a little bit better about saying no to people who just show up with one-time patches for obscure operating systems, unless they can commit that they're going to stay around and keep updating that. Yeah? What is the list long? Can you tell us what else is on it for the list of systems? Yeah. That's what it looks like. These are sort of like our first class candidates here. They're the ones that are really getting done on basically a daily basis. These are the ones that we support, but it's not as good. And we would prefer if people could do more stuff about that. Yeah, so that's it. OK, thank you. And we also have tool chain requirements, where we say your compiler must support these features as well, even if they're not necessarily mandated by POSIX. And that page I just flashed up really goes into details about why we chose this approach. And one of the things that that page mentions is that you can't build something like an O on top of POSIX. You just can't do it. I mean, POSIX is great. I love it. It's very well-written. It tends not to be too ambiguous. You get a very good idea of what you're allowed to do by POSIX, but it's simply not enough. Really simple things like power management, completely silent on this topic. How do I change the system time zone? I don't know. Left to the vendor to decide. POSIX is really minimal. We need more than that. And what I was saying before, you can talk about, OK, we're adhering to POSIX, so it should work on all systems. But in practice, that doesn't work either. Because there's always something that, even if you think you followed the spec, you actually didn't. And you're using some specific behavior that is only on Linux or something. And you don't know that when you run it on other systems, even if they are POSIX compliant, that it's going to break horribly. And unless you're actually testing on those systems, you're never going to find out about that. And that brings me to an important point, which is that nobody in GNOME like hates FreeBSD or any of the BSDs. There's this idea going around that it's really true. But it's not. I mean, some people are like BSD friendly. Some people couldn't give a damn, I think, is probably a good way of describing it. Just like, OK, whatever, you're over there. But nobody is actively hostile. And even like the people who don't really care, if you show up with patches in hand, they're generally pretty good about applying them. It really is just a matter of we make mistakes. What can we do? We all are running Linux in GNOME for the most part. When we write code, occasionally we depend on a feature. We don't realize this is in POSIX. Honest mistake. And it's really good. And we appreciate it if people are calling us out on this stuff. But there is another kind of issue, which the stuff I was saying about stuff that's not in POSIX. In GNOME, we have this approach where we call it draining the swamp. And basically, it's, OK, everything's crap. We need to build some feature. We can't do it with what we have here. So we need to plumb through the whole platform layer in order to get what we want. And that often means that we're writing new stuff, like things like systemD, in fact, coming originally from someone quite involved in the GNOME project. And these things are doing useful stuff for us, like what I mentioned before about an API for changing the time zone or the date and time or changing the host name or stuff like this. Before in GNOME, these were parts of GNOME. And they were done in system-dependent ways in this weird back end with lots of FDF that nobody ever looked at. And it was running as root. And we're happy not to have that in our code if we can depend on a feature that's provided by the operating system. So why it's interesting for me to focus on the BSDs a little bit more is because from the standpoint of GLib, sure, we have to support Windows and Mac and all that. But GNOME itself doesn't target Windows and Mac. So if not operating systems like BSD, GNOME as a desktop is basically a Linux-only affair. So having another platform that we can target is quite useful for us in terms of going from it's theoretically portable to it's actually portable. And even just having just one like pre-BSD, for example, you find really a lot of the portability issues just because there's a different compiler. So I mean, Clang and GCC kind of in some ways are the same compiler because they support all the same features. But you do find a lot more bugs just by having one other C compiler. And then after that one extra, you get maybe three C compilers, you get diminishing returns here quite quickly. Same with Live-C kernel. Anything else, just having that one extra is going to find really a lot of portability issues because any Linux specific feature, instantly you find out about it. In addition to portability issues, do you find that you improve your code overall by having a hybrid and having it work on more than one compiler? It's an interesting question. Sometimes that's true. It's actually often false. Because so to give an example of something that we recently added support for in GLib, that depends on a GCC feature. And therefore, we cannot use it in GLib itself, there's a thing called a cleanup attribute in GCC, which is phenomenally useful. And it allows you to define an attribute on a local variable that when it goes out of scope, it automatically gets a function called on it that will free it or whatever. This could phenomenally improve our code quality. And we can't use it because we have to be portable, right? We often run into things like this, that if only we had this compiler feature everywhere, we could do this thing that would make our code really a lot more readable, a lot better quality. Yeah. Sometimes you're forced to go to the lowest common denominator. Yeah, and that does hurt code quality often. I mean, you are in a RIA GCC, or is RIA need? And you're the supported compiler because Clam has the cleanup stuff? Yeah. Again, in lots of GNOME projects, use the cleanup stuff. Oh my goodness. Yeah, sorry, I'm giving a talk. Lots of GNOME stuff that only targets Linux and free GSC will use that stuff. But in GLib, we also have to target macOS and Windows. Well, macOS, again, wouldn't be a problem. But we target Visual Studio, so it's a no go. And in theory, if you want to use the Intel compiler, the Sun compiler, that stuff is still supported in GLib. So yeah, we can't rely on that feature, which is unfortunate, and I'd like to. But yeah, often if you try and support multiple systems, it does force you to think in a more abstract way. And sometimes that leads to improvements. But I'd actually argue that honestly, just being able to do it once and do it a certain way is almost always better from the code being cleaner, actually. Fewer abstractions, I think, can actually be a good thing, just because it's less code overall, right? So yeah, so a little more detail about what I was talking about earlier, sort of going back over to the free VSD side of things now. There was GNOME 2 in ports forever after GNOME 3 was released. The uphill battle I was talking about with the new versions, it was hard to stay up to date with that. So a while ago, I approached the GNOME VBSC team and said, hey, there's a single JH build. I think you guys should run it. And what JH build is for those who don't know is it's sort of like a meta build system. GNOME is really very large. It's like if you talk about it and it's closely related external dependencies, you're talking like 160 tar balls, more or less. And building all of those is a bit of a pain. So we have JH build, which does that for us. And it'll go and download, and then it'll configure it, make, make, install. And it does something cool. You can install it in your home directory. And then it'll set up in a bunch of environment variables, like LD library path and all that stuff, so that when you build the next module, which depends on that first one, it can find the include files and the libraries and all that in your home directory. So you can do this without messing up your system. And one of the, yeah, sure. I was just going to ask what JH stands for. James Henstridge. He's the guy that wrote it. OK. Little bit of a history there. He's a cool guy. One of the really cool things about JH build, though, is that it's default mode of operation, is that it takes all of the software out of Git. And it takes it out of Gitmaster. So if you want to know what's in GNOME like today, as of the thing that got committed five minutes ago, you can compile it with JH build and you're going to get that. The reason that's really cool is you can really keep track of any issues that might be sneaking into the code at any given time. And certainly, if we're doing that on FreeBSD, then we get a really good idea of any potential portability issues that are sneaking into the code at any given time, which is wonderful. And this is where that whole Stitch in Time stage nine thing comes in. When you find somebody did a commit that caused a problem, or you find maybe we're doing it once a day, it worked yesterday. It doesn't work today. So maybe there's like 10 commits. Yeah, this looks like the one that caused the problem. I can email that person. It's fresh in their mind. I can file a bug about it. They're probably going to have some idea of what they can do to fix it at that point. Versus if I'm waiting six months or a year later when the release comes, it's not working. Oh, geez. OK, what changed? I don't even know how to track this down. Who's fault it is? Even if I do figure out what commit it is, I go to that person. OK, do you remember this thing you did a year ago? Yeah, it's causing me trouble now. Can you reevaluate that? Well, no, sorry. I'm like, I'm totally something else now. I can't do that for you. So the FreeBSDEGENOME team, Cope has been a big part of this, is basically every day running JH build on FreeBSDE now, at least once a day. And Ting Wei Lan, also another person who's doing this very actively. And when stuff breaks, they're filing bugs upstream right away. And this isn't just portability bugs. I mean, we have continuous builders as well running on Linux in Genome. But sometimes the BSD guys are the first ones who find problems where it's just like, did you actually test this before you committed it? And these bugs are going upstream too. And this has really resulted in a fundamental shift in the relationship, I think, between FreeBSDE and Genome. Because when Genome contributors and Genome hackers and maintainers have really become accustomed to receiving bug reports from FreeBSDE people now. And they're pretty good, in my opinion, about replying to them. We have a Wiki page, actually. I should pull that up. It sort of details everything that's been going on. And as we've done, it's a list of fixed bugs. Yeah, so this page is huge. I mean, you see the scroll bar there. It's really impressive. Like, this is, if you want to get it set up, you've got to do all this stuff. Yeah, these are the outstanding issues in Genome, which is some low priority stuff. But the most impressive thing is like this, are the issues that we've solved. And that goes on. It's just a huge number of patches that were sent upstream and applied by upstream happily for addressing FreeBSDE portability issues. And that list is growing all the time. One patch rejected upstream, which I think is pretty cool. That was a patch against Udev. And I talked to the maintainer about that recently, and he might change his mind. So the response from upstream has been great about that. Yeah, so that's really good. Yeah, as I said, you all saw the list. It's pretty good. And it's just getting bigger. So what do we do? So one of the things I was mentioning is about how POSIX is not good enough for us. So we're doing things like log-in D for power management and stuff, and figuring out which session is the active one. And we're depending on things like Udev for enumerating hardware and all that. And this is my opinion. And it's something that I've talked about with the release team of Genome. And they're sort of on board with this idea. The approach to portability that I like is that you depend on an API, not a particular piece of software in name. And when I say an API, I mean a header file that you include that has a certain set of symbols of a given name in it, or a PC file, a packaging fig, that you link into your project, and again, gets you a certain set of symbols that you can use in the project. So this is for things like, say I wanted to enumerate all the webcams on the system, it would be good if I had just a single PC file that I could include that got me an API that looked a certain way that I could use. And I could do that everywhere. That would be really great for me from the upstream standpoint. As it turns out, we have this. It's Udev on Linux right now. It's not the most portable API. There's nothing stopping people from implementing it, per se, but I can understand why people wouldn't want to, because it's very Linux specific. It's putting stuff from the kernel in there. And other things like the log-in D APIs or the other system D service APIs, I think they're really good APIs. And I wish people would just implement them. And it would never be our intent to depend on system D, for example, but to depend on anyone who's willing to provide these APIs. And in my opinion, that is sort of the best approach to portability. Because for lack of that, I'm basically having to write different back ends to put if-desk in my code and stuff like that. So we do need to depend on more than just POSIX. But in a way, POSIX kind of gives us a good idea about, well, why don't we write a spec for what we expect from the operating system? And then everybody can implement that spec. And one of the cool things about a lot of system D is it has a wiki page where it says, here's the various APIs that we implement in system D. And here are the ones that we think should be reasonably portable to other systems. And by the way, here's where they are documented. And this documentation is firm. And we don't plan on changing the API. And on that topic is, I think system D. I mean, if you look at it, we sort of did Hal and DeviceKit. And we did DevFS we had. We're getting to a place. And I mean, before, as I said, we sort of started out in this damn point of GNOME, we need to do stuff. How do we get this stuff done? It all sucks. What can we really do about it? So we started doing things. And it was kind of at a point where D-Bus was new. We were kind of getting a grasp of how we write good D-Bus services. Hal did what we needed it to do for a while. But it was clearly sort of an experimental foray into this new world. And it wasn't great. And similarly, ConsoleKit, it did what it needed to do, but it wasn't great. So we're sort of now at a point where we have, and really a lot of this is being done under the banner of system D, we have for the first time something that people actually feel good about. And that is good. And I think that it's going to be around for a while. So when BSC people ask me, well, we did the Hal thing. And then you guys, like, ripped the carpet out under us. Are you going to do the same thing with system D? I don't think so. I think system D is here for a while. So basic stuff about just what I think anybody who's interested in any kind of large software project porting it to BSD is get upstream. If you're maintaining patches in the port's tree, you're probably doing something wrong. But not always. Because get upstream first. This is something that I've been involved in Ubuntu for a long time. And Ubuntu is definitely a project that has an interesting history with the GNOME project as well. It hasn't always been friendly. But we sort of developed a certain protocol of what is considered good behavior for interacting with upstream projects. And upstream first is basically the number one principle. If you've got a problem and you need to fix that with a patch, you're fine. But you need to fix that with a patch. Your first step should be getting that patch upstream. Where the first comes in is that, OK, so you sent it upstream, and now they're ignoring you because the maintainer is busy or whatever. By all means, put that in the port's tree as a patch against the package. But when you do that, make sure at the top of it, as a description, as part of it, provide a link to the bug. Explain why it's needed. And maybe even give them a week to see if they can get it in. Maybe they change it a little to make it a little bit better in some way that only they would know how to do because it's their project. You get a better patch by doing that. So I'm kind of getting to the end of the main thesis of this thing. So I'm just going to throw on a bunch of points here. I kind of thought the audience would be a bit bigger. I have to admit. My wish list items for things that could be better in DSD. Getting this stuff implemented would be really nice. I baptized. Yeah, KQ64 would be good, mostly because it would let us set KQ events for absolute monotonic time with microsecond or nanosecond accuracy. Because if you only have 32-bit counters and you want microsecond or nanosecond accuracy against the monotonic time, that stops working after some number of days of uptime. So you basically need the 64-bit for that. Yeah, this sucks. Please, some kind of a file notification API would be good. It does not suck. It's not done for what you want. So we need something new along with it. It sucks that I have to use this. Yeah, that's it. Yeah. But on that topic, if we could make this a little bit better, I would ask for the implementation of this. Which is something. Yeah, this macOS has this. And it makes a Filt Vnode slightly less horrible. Basically, you can open a file like this, just like Oread Only or Oread Write, you say OEVT only. And you can't do anything with the file except stick it in a KQ. And then you get notifications about changes. And the biggest difference there is that you can actually unmount the file system that you did this on. So we can watch for files on removable media. Yeah, because right now we have to pull, basically. So that would be good. Get on the recording. If that said that, it would be easy to do. Yeah. So Baptiste says that this will be very easy to implement. And he plans on doing it next week. No. No? Tonight? Oh, even better. Just some miscellaneous stuff. Some of it's on that web page. LibTool is still setting our path in inappropriate ways on BSD. It would be cool if it could stop doing that. But it just takes that to the lower end. So you stopped installing LA files for the most part. You're not installing LA files most of the time, or if you install them, they are empty? But our path is still getting set, which is annoying. I think we changed that. OK. Just to check. But the appropriate way. Yeah. Well, if you look in your JH build install directory, just look on the libraries and see if they have an R path. And if they don't, then it's good. But if they do, and I think that they do. This is another huge one. As I said, what we consider an API is often the package config file. And there's a lot of things in the base system in BSD that implement APIs that we would expect have package config files, and they don't. So we have to hack, configure arguments in order to get them registered. Yeah, but usually some of those, because I think I listen to help, not in really yet. But I think we are managing all the missing PC files. So basically, LibRKai, everything which is things like ZLib and stuff. OK, that's good. I see MA and stuff like this. Is it? Sorry? Except here. Open as a no-suit. I'll open it, though. We don't have the And since you're working on, what's the one you're working on tonight? You're working on the OEVT only tonight. So tomorrow night, you have to work on this one. That'd be really cool. If I could ask, which package do I have to install in order to get this file on my system? This one, we have it in the total is for Y, and it's not implemented for one written write note, because the database would be too huge. So the idea is to go through the A-V-T way and having a separate database so that you can have an accurate amount of A-V-T file. Actually, package repo does. Is I really able to create that, just a matter of instrumenting that all the stuff in the hood is already available somewhere? Yeah, so this would help a lot, because JHBuild has a feature called SysSteps. And as I said, GNOME has a ton of dependencies. And maybe you saw at the start of that wiki page, it said, type PKG install this. And JHBuild is actually able to figure out that itself if it has some way of saying which package provides this file. So that'd be cool. And here's one I just turned in. That's pretty funny. You have this libg-aum in FreeDSD. And most functions in it are a g-aum underscore. Some are gctl underscore, and some are g underscore. And there's another popular library that also uses g underscore. And yeah, we both have this symbol. So no GNOME program can look against libg-aum, which is a problem for gtop. So in some ways, I kind of wanted to start a conversation. I'm pretty much done with the slides now. If anybody wants to talk about experience they've had, or like, I approach the GNOME developer once and this happened, and can you help me out with this, that'd be pretty cool. I just like the idea that it sounds like the project initially didn't really. I mean, there's tradition in rivalry between projects, but it's usually over the long run. It's usually a sibling rivalry, where they're really involved in the long run. Yeah, like GNOME, Katie, or whatever. Yeah. Yeah. But I like the idea that once they found there was valuable information in the form of PRs, or bug reports, in that case, from another project, it probably didn't matter to them what other project it was, as long as the information was valuable. And it's like, hey, it turns out they're our friends. Yeah, and my approach to that has always been, well, at least my new approach since a couple of years ago when I decided, let's make everybody happy thing just isn't working anymore. If somebody's willing to show up and do it regularly, and it's certainly if it's going to improve my code quality, by all means. And if I've done something that's Linux specific, and there's a better POSIX equivalent, and there's nothing worse about it, then by all means I'm happy to use that one. And I think almost anybody would do this. We get things like, oh, you're assuming a bash feature in DNSH, you can't do that. Everybody's happy to fix those kinds of bugs. Right, but I think there are a lot of people who think that, oh, there another project, they're not going to want our input anyway. Yeah, that's absolutely. Right, but I think that is a common misperception that should be directed. Yeah, and if. I mean, Linux said openly that he didn't care about anything from the bottom of his head. So, Leonard, yeah. That's not entirely true. He said that he didn't care. He doesn't want to implement compatibility in such a system for that, but it makes sense, because it's mainly some of this stuff. I mean, our init doesn't have any compatibility with something else. The problem after that is a stock of what system it does. All of these parts couldn't be portable. But the reason why they don't want to get any patches from the BSD makes, in my opinion, sense, because we don't want Linux patches in our init. To tell you the truth, having talked to Leonard a lot on this topic, he is actually actively anti-BSD. He is one of the few people I know who I would actually say. He wishes that all of the BSDs would just die so that everybody focuses on Linux instead. But he is the only one I know, like the singular person I know that has this extreme attitude on the topic. So some of the CIO might think he would almost like this. Maybe you could use the BST gap. No, I don't think he would come. I don't think he would come. Bastion, I think we have this Ganomo-S idea, which is we want to build this whole operating system, start from Linux and all this stuff all the way up. And Ganomo-S to different people means a lot of different things. And one thing it was was this continuous integration. We would build this image for virtual machines that we could test and do it every day. Actually, we do it on every commit. And this is a part of what that was. But what it mostly was, in my opinion, is just a list of things that you have to have in your system in order for it to be considered a Ganomo-S. This has to work properly. This has to work properly. We need this. And I would say that free BSD doesn't meet those criteria, but only because you don't have things like network manager. And if you got all of these things and it was working at the same level, I wouldn't necessarily say that this couldn't be Ganomo-S in the same sense, even. One of the things I really like to see the GNOME project do is when they rely on something which is not directly GNOME project like Logizy or network manager or whatever, that they do actually list the actual API from it they rely on so that if we are to create some kind of wrapper on top of our own libraries and provide the same API, we can have at least the first level of subset API we need to do. And probably later, some people will be improving it. But having this list, I mean, following it, for example, I'm not sure. I think you don't rely on that many API. Yeah, so this is a conversation I've had with the SystemD guys a couple of times. And in fact, that one rejected patch that was on my Wiki page is basically this. And this goes back to what I was saying that, for me, an API is a package config file. And saying that, OK, you implement this API and you provide this package config file, but it only implements a subset of the APIs, to me, that's never going to cut it. I don't like that. What I would rather, and that's what this bug was about, is if there's something like Logindy that has a whole bunch of things in one API, a lot of them not related to one another, well, then really maybe that's three APIs. And we're talking D-Bus there, so it doesn't make as much sense. But in this case, it was Udev. And you had all the Udev APIs. And then separately, you had this hwdb thing where you could look up PCI IDs and stuff like that. And this was all grouped together under a single API, one package config file. And we wanted to just use the hardware dblookup, which in no way depended on anything in the kernel. It was basically a hash table lookup in a database file. There's no reason that couldn't have been separate. And having that as a separate package fig and therefore a separate API, in my opinion, is something I wanted. Yeah, but what I mean by that is we have started for Xorg and we're going to extend it for a lot of things, a project libdev queue, which current devices basically. So the idea is to provide an equivalent high-level API that you can get through Udev or Udev like stuff. And if you want to do a priority on what kind of query you want to do first, then if you have a list of what you expect from Udev extracting the Wikipedia or whatever, then we know that probably the priority is to how concurrent this kind of hardware or this kind of hardware events for this kind of stuff. And so that we can have something which is good enough for node to be able to use along with. But is your intent to provide like a Udev API or to provide an equivalent API? Well, the goal of the Dvd queue is to have to provide their own API and back end for basically anything. So the goal is to be able to unify all non-vinducts of writing systems that right now doesn't have a Udev API. They want to get just plug into our version of the same kind of primary so that if you don't know, you just have to. Yeah, so in my opinion, this is unacceptable, in fact. I don't want a situation where normal applications are expected to deal with one API or another. This is really a good backend that you have on the hour library. Something that I think would be far more likely, and people would find to be more acceptable, is that we put something in GIO, for example, which wraps both of them and provides an even higher level and nicely geobjectified API. And we deal with the abstraction in GLib. Because I really don't consider it in any way appropriate that normal applications should have to do this. Yeah, the truth is to me. But anyway, I need to know what GIO in that case would expect from the operating system. So that when I'm on my library, I know that my priority is on this, this, this. This is cool, but no one needs this stuff for portability yet. Yeah, and that's something that I wanted to work on. It's something that's on the wakey page, is something we should get this. But it's not something that I personally have a lot of time to work on right now. I got pulled into a lot of stuff like with application confinement stuff, which is pretty interesting work too. But if somebody wanted to undertake a project of making a high level wrapper in GIO that would wrap Udev and also equally well wrap whatever BSD API is going to be forthcoming, that would be a project I'd be very much interested in. And that's the kind of thing that GNOME people would even like, because Udev, it gets the job done. It's not a great API, right? So if they could have a nicer API that's easier for them to use and be more portable at the same time, that's just a win for everybody. Yeah, because we just cannot create the Udev API because it exposes some internal links. Yeah, insert weird string here. So there's all the system stuff which is exposed, and we can't explore the same thing. So you will need it. If you want probably to do this on the BSD, you will need anyway to get your abstraction on GD for that. Yeah, as far as I see it, that would be pretty much the only acceptable way forward for GNOME. Having any application if deaf or whatever would not be good. For us, it even better because even things which are relying on GD, but not GNOME, we can just talk to them and say, use your abstraction. We know that we just have to focus on GD to get the portability. Yeah, so if anybody wanted to work on this kind of thing, I'd really be happy to mentor this project and say, OK, this is what I think the API should look like, and then go and do it. I'd be happy about that. Could it be a sub-ref course for the next year? Yeah, it could be. And again, for LoginD, there's a lot of APIs in LoginD that we need to use. But again, it's only a subset of some of them. And exposing that subset in a nice way through G object could also be something that's appealing. Although LoginD has a pretty decent API already. But there are some things like it makes you deal directly with file descriptors for the suspense stuff, and probably most people would rather deal with the G object instead, for example. Cool. Thank you for coming. Oh, sorry. Yeah. Have you Germany thoughts on the different file system event notification APIs that exist? Have they're? Yeah, Apple does it best, I think. Even I Notify is pretty crappy. I hate I Notify. But even I Notify is like a world better than what is available in previous data. Yeah, so we're looking at, on behalf of the database accrediting world, looking at a fund project to handle something like I Notify. Yeah, I hear there is an idea that instead of queuing up an FD inside of KQ, you could tell it about an I node instead, right? Well, there's a whole bunch of different ideas, but I'm just curious if we're trying to figure out what the best method for it would be. And an option on the table is we'll make an FS events compatible database. Yeah, FS events is good for most high level things, I'd say. But it doesn't work the way that we kind of have our API working in Glib, in fact. It's more like what changed since where Glib is more about online all the time. And it's not interested in something that happened when the system was down, because the API just doesn't expose this concept. I'd say if I were to tell you the things that I don't like about I Notify, for example, one of them would be that it's extremely difficult to know which file I'm actually monitoring. Because if you imagine, I think about race conditions a lot. And if I imagine I have somebody basically actively attacking my algorithm to monitor files, I could imagine I get into a situation where I have a bunch of files being renamed. I notify a file named A, which then gets renamed out from under me. And then I stat the file. And even if I stat the file on both sides of telling I Notify, watch that file, I could think that I'm monitoring an I node that's different from the one that I Notify actually caught. And that disturbs me a lot. And then it's moved. And now I don't know, OK, so it's moved. So the thing that I think I'm watching is not actually the thing that I'm watching. So you get into situations where you have to watch the parent directory to make sure that no moves occurred on it. And then you have to watch a parent directory, parent directory. This is a bit of a mess. I mean, in a certain sense, the KQ thing's a little bit better that way, because at least I have the FD in hand. And then I can put that in KQ, and I can F stat the FD. So at least I know that it's the same thing. So that's a little bit nice, I guess. But without EVT only, having that FD open is also a risk. Because even if I only have it open for a millisecond, if somebody tries to unmount that file system at that exact point, it's not going to wait for me to close it. It's just going to tell them, no, I can't. And that's a problem, too. Yeah. OK. Yeah. Yeah, file system notification is something I thought a bit about. Maybe we could talk about that after. Sure. OK, thank you. Thank you all for coming.
 Can you just introduce yourself?  Oh, yeah.  OK.  So I'm Ryan Lorti.  I'm a member of the GNOME project for a long time.  And a small while ago undertook improving the relationships  of GNOME and FreeBSD.  So yeah, I guess that's the introduction, in fact.  So I noticed that there were two big problems.  And I was sort of approaching it from the problem  that GNOME had.  But there was also a problem in FreeBSD,  which was that GNOME on FreeBSD was not happy.  There was version two in the ports.  Like version three came out.  And it was many, many years.  And there was still version two in there.  And it was kind of a bad situation,  because GNOME is big and unwieldy,  and it tends to touch a lot of things.  And every time a new version came out,  it would be like, OK, what's broken now?  OK, well, everything's broken.  So we've got to file a bunch of bugs, get it fixed upstream.  Hopefully, it'll be fixed in the next version.  OK, great, it's fixed.  But now a whole bunch of other stuff is broken.  And this was just because if you're  doing something only once every six months  or even sometimes longer, it's not fast enough  to catch the problems as they're happening.  On the other side, I maintain G-Lib, which is sort of like  the base library of GNOME.  And it's kind of a mess when it comes to portability.  We have so much stacks of if def code around certain things  like stat and stat VFS and stat FS.  And just basic stuff like, how do I  figure out how many free blocks there are in this file system?  There are about eight different ways  of doing this, depending on the operating system you're on,  like old versions of Solaris and stuff.  I don't even know how much of that code we use.  This is a problem for me, because I kind of want to rip it out.  And I'm kind of wondering, well, if I rip it out,  is somebody going to get angry at me?  Am I going to get hate mail?  I don't know.  So wouldn't it be nice if we had an actual set of supported  systems that we knew that we supported,  and we had a way of testing those systems?  So we sort of decided in G-Lib.  And if G-Lib does something and says, this is the way it is,  it's pretty much affecting all of GNOME,  because you need G-Lib to run GNOME.  So we said, we're going to move away from this idea  that we theoretically support anyone who wants to come to us.  And we're going to try and nail down more concretely.  An idea of we support these platforms,  because we care about them, and we  know we support them because we actually tested it.  It's not just theoretical, hey, somebody sent me a patch  a long time ago.  Maybe it's still working.  It's something that we're testing regularly.  So we have a list of platforms that we actually target.  And we actually do test regularly on most of them.  And we've gotten a little bit better  about saying no to people who just show up  with one-time patches for obscure operating systems,  unless they can commit that they're going to stay around  and keep updating that.  Yeah?  What is the list long?  Can you tell us what else is on it for the list of systems?  Yeah.  That's what it looks like.  These are sort of like our first class candidates here.  They're the ones that are really getting  done on basically a daily basis.  These are the ones that we support, but it's not as good.  And we would prefer if people could do more stuff about that.  Yeah, so that's it.  OK, thank you.  And we also have tool chain requirements,  where we say your compiler must support these features as well,  even if they're not necessarily mandated by POSIX.  And that page I just flashed up really  goes into details about why we chose this approach.  And one of the things that that page mentions  is that you can't build something like an O on top of POSIX.  You just can't do it.  I mean, POSIX is great.  I love it.  It's very well-written.  It tends not to be too ambiguous.  You get a very good idea of what you're allowed to do by POSIX,  but it's simply not enough.  Really simple things like power management,  completely silent on this topic.  How do I change the system time zone?  I don't know.  Left to the vendor to decide.  POSIX is really minimal.  We need more than that.  And what I was saying before, you can talk about, OK,  we're adhering to POSIX, so it should work on all systems.  But in practice, that doesn't work either.  Because there's always something that, even if you think  you followed the spec, you actually didn't.  And you're using some specific behavior that is only  on Linux or something.  And you don't know that when you run it on other systems,  even if they are POSIX compliant,  that it's going to break horribly.  And unless you're actually testing on those systems,  you're never going to find out about that.  And that brings me to an important point,  which is that nobody in GNOME like hates FreeBSD  or any of the BSDs.  There's this idea going around that it's really true.  But it's not.  I mean, some people are like BSD friendly.  Some people couldn't give a damn, I think,  is probably a good way of describing it.  Just like, OK, whatever, you're over there.  But nobody is actively hostile.  And even like the people who don't really care,  if you show up with patches in hand,  they're generally pretty good about applying them.  It really is just a matter of we make mistakes.  What can we do?  We all are running Linux in GNOME for the most part.  When we write code, occasionally we depend on a feature.  We don't realize this is in POSIX.  Honest mistake.  And it's really good.  And we appreciate it if people are calling us out on this stuff.  But there is another kind of issue,  which the stuff I was saying about stuff that's not in POSIX.  In GNOME, we have this approach where  we call it draining the swamp.  And basically, it's, OK, everything's crap.  We need to build some feature.  We can't do it with what we have here.  So we need to plumb through the whole platform layer  in order to get what we want.  And that often means that we're writing new stuff,  like things like systemD, in fact,  coming originally from someone quite involved in the GNOME  project.  And these things are doing useful stuff for us,  like what I mentioned before about an API for changing  the time zone or the date and time  or changing the host name or stuff like this.  Before in GNOME, these were parts of GNOME.  And they were done in system-dependent ways  in this weird back end with lots of FDF that nobody ever  looked at.  And it was running as root.  And we're happy not to have that in our code  if we can depend on a feature that's provided  by the operating system.  So why it's interesting for me to focus on the BSDs  a little bit more is because from the standpoint of GLib,  sure, we have to support Windows and Mac and all that.  But GNOME itself doesn't target Windows and Mac.  So if not operating systems like BSD,  GNOME as a desktop is basically a Linux-only affair.  So having another platform that we can target  is quite useful for us in terms of going from it's  theoretically portable to it's actually portable.  And even just having just one like pre-BSD, for example,  you find really a lot of the portability issues  just because there's a different compiler.  So I mean, Clang and GCC kind of in some ways  are the same compiler because they support all the same features.  But you do find a lot more bugs just  by having one other C compiler.  And then after that one extra, you get maybe three C  compilers, you get diminishing returns here quite quickly.  Same with Live-C kernel.  Anything else, just having that one extra  is going to find really a lot of portability issues  because any Linux specific feature,  instantly you find out about it.  In addition to portability issues,  do you find that you improve your code overall  by having a hybrid and having it work on more than one compiler?  It's an interesting question.  Sometimes that's true.  It's actually often false.  Because so to give an example of something  that we recently added support for in GLib,  that depends on a GCC feature.  And therefore, we cannot use it in GLib itself,  there's a thing called a cleanup attribute in GCC,  which is phenomenally useful.  And it allows you to define an attribute on a local variable  that when it goes out of scope, it automatically  gets a function called on it that will free it or whatever.  This could phenomenally improve our code quality.  And we can't use it because we have to be portable, right?  We often run into things like this,  that if only we had this compiler feature everywhere,  we could do this thing that would make our code really  a lot more readable, a lot better quality.  Yeah.  Sometimes you're forced to go to the lowest common denominator.  Yeah, and that does hurt code quality often.  I mean, you are in a RIA GCC, or is RIA need?  And you're the supported compiler because Clam has the cleanup stuff?  Yeah.  Again, in lots of GNOME projects, use the cleanup stuff.  Oh my goodness.  Yeah, sorry, I'm giving a talk.  Lots of GNOME stuff that only targets Linux and free GSC  will use that stuff.  But in GLib, we also have to target macOS and Windows.  Well, macOS, again, wouldn't be a problem.  But we target Visual Studio, so it's a no go.  And in theory, if you want to use the Intel compiler,  the Sun compiler, that stuff is still supported in GLib.  So yeah, we can't rely on that feature,  which is unfortunate, and I'd like to.  But yeah, often if you try and support multiple systems,  it does force you to think in a more abstract way.  And sometimes that leads to improvements.  But I'd actually argue that honestly, just being  able to do it once and do it a certain way is almost always  better from the code being cleaner, actually.  Fewer abstractions, I think, can actually be a good thing,  just because it's less code overall, right?  So yeah, so a little more detail about what I was talking  about earlier, sort of going back over to the free VSD  side of things now.  There was GNOME 2 in ports forever  after GNOME 3 was released.  The uphill battle I was talking about with the new versions,  it was hard to stay up to date with that.  So a while ago, I approached the GNOME VBSC team  and said, hey, there's a single JH build.  I think you guys should run it.  And what JH build is for those who don't know is it's  sort of like a meta build system.  GNOME is really very large.  It's like if you talk about it and it's  closely related external dependencies,  you're talking like 160 tar balls, more or less.  And building all of those is a bit of a pain.  So we have JH build, which does that for us.  And it'll go and download, and then it'll configure it,  make, make, install.  And it does something cool.  You can install it in your home directory.  And then it'll set up in a bunch of environment variables,  like LD library path and all that stuff,  so that when you build the next module, which  depends on that first one, it can find the include files  and the libraries and all that in your home directory.  So you can do this without messing up your system.  And one of the, yeah, sure.  I was just going to ask what JH stands for.  James Henstridge.  He's the guy that wrote it.  OK.  Little bit of a history there.  He's a cool guy.  One of the really cool things about JH build, though,  is that it's default mode of operation,  is that it takes all of the software out of Git.  And it takes it out of Gitmaster.  So if you want to know what's in GNOME like today,  as of the thing that got committed five minutes ago,  you can compile it with JH build and you're going to get that.  The reason that's really cool is you  can really keep track of any issues that might be sneaking  into the code at any given time.  And certainly, if we're doing that on FreeBSD,  then we get a really good idea of any potential portability  issues that are sneaking into the code at any given time, which  is wonderful.  And this is where that whole Stitch in Time  stage nine thing comes in.  When you find somebody did a commit that caused a problem,  or you find maybe we're doing it once a day,  it worked yesterday.  It doesn't work today.  So maybe there's like 10 commits.  Yeah, this looks like the one that caused the problem.  I can email that person.  It's fresh in their mind.  I can file a bug about it.  They're probably going to have some idea of what  they can do to fix it at that point.  Versus if I'm waiting six months or a year later  when the release comes, it's not working.  Oh, geez.  OK, what changed?  I don't even know how to track this down.  Who's fault it is?  Even if I do figure out what commit it is, I go to that person.  OK, do you remember this thing you did a year ago?  Yeah, it's causing me trouble now.  Can you reevaluate that?  Well, no, sorry.  I'm like, I'm totally something else now.  I can't do that for you.  So the FreeBSDEGENOME team, Cope has been a big part of this,  is basically every day running JH build on FreeBSDE now,  at least once a day.  And Ting Wei Lan, also another person who's  doing this very actively.  And when stuff breaks, they're filing bugs upstream right away.  And this isn't just portability bugs.  I mean, we have continuous builders as well running  on Linux in Genome.  But sometimes the BSD guys are the first ones  who find problems where it's just like,  did you actually test this before you committed it?  And these bugs are going upstream too.  And this has really resulted in a fundamental shift  in the relationship, I think, between FreeBSDE and Genome.  Because when Genome contributors and Genome hackers  and maintainers have really become  accustomed to receiving bug reports from FreeBSDE people  now.  And they're pretty good, in my opinion,  about replying to them.  We have a Wiki page, actually.  I should pull that up.  It sort of details everything that's been going on.  And as we've done, it's a list of fixed bugs.  Yeah, so this page is huge.  I mean, you see the scroll bar there.  It's really impressive.  Like, this is, if you want to get it set up,  you've got to do all this stuff.  Yeah, these are the outstanding issues in Genome,  which is some low priority stuff.  But the most impressive thing is like this,  are the issues that we've solved.  And that goes on.  It's just a huge number of patches  that were sent upstream and applied by upstream  happily for addressing FreeBSDE portability issues.  And that list is growing all the time.  One patch rejected upstream, which I think is pretty cool.  That was a patch against Udev.  And I talked to the maintainer about that recently,  and he might change his mind.  So the response from upstream has been great about that.  Yeah, so that's really good.  Yeah, as I said, you all saw the list.  It's pretty good.  And it's just getting bigger.  So what do we do?  So one of the things I was mentioning  is about how POSIX is not good enough for us.  So we're doing things like log-in D for power management  and stuff, and figuring out which session is the active one.  And we're depending on things like Udev for enumerating  hardware and all that.  And this is my opinion.  And it's something that I've talked about with the release  team of Genome.  And they're sort of on board with this idea.  The approach to portability that I like  is that you depend on an API, not a particular piece of software  in name.  And when I say an API, I mean a header file  that you include that has a certain set of symbols  of a given name in it, or a PC file, a packaging  fig, that you link into your project,  and again, gets you a certain set of symbols  that you can use in the project.  So this is for things like, say I wanted to enumerate  all the webcams on the system, it  would be good if I had just a single PC file that I could  include that got me an API that looked a certain way  that I could use.  And I could do that everywhere.  That would be really great for me from the upstream standpoint.  As it turns out, we have this.  It's Udev on Linux right now.  It's not the most portable API.  There's nothing stopping people from implementing it, per se,  but I can understand why people wouldn't want to,  because it's very Linux specific.  It's putting stuff from the kernel in there.  And other things like the log-in D APIs or the other system  D service APIs, I think they're really good APIs.  And I wish people would just implement them.  And it would never be our intent to depend on system D,  for example, but to depend on anyone who's  willing to provide these APIs.  And in my opinion, that is sort of the best  approach to portability.  Because for lack of that, I'm basically  having to write different back ends  to put if-desk in my code and stuff like that.  So we do need to depend on more than just POSIX.  But in a way, POSIX kind of gives us a good idea about,  well, why don't we write a spec for what we expect  from the operating system?  And then everybody can implement that spec.  And one of the cool things about a lot of system D  is it has a wiki page where it says,  here's the various APIs that we implement in system D.  And here are the ones that we think  should be reasonably portable to other systems.  And by the way, here's where they are documented.  And this documentation is firm.  And we don't plan on changing the API.  And on that topic is, I think system D. I mean, if you look at it,  we sort of did Hal and DeviceKit.  And we did DevFS we had.  We're getting to a place.  And I mean, before, as I said, we sort of started out  in this damn point of GNOME, we need to do stuff.  How do we get this stuff done?  It all sucks.  What can we really do about it?  So we started doing things.  And it was kind of at a point where D-Bus was new.  We were kind of getting a grasp of how we write good D-Bus  services.  Hal did what we needed it to do for a while.  But it was clearly sort of an experimental foray  into this new world.  And it wasn't great.  And similarly, ConsoleKit, it did what  it needed to do, but it wasn't great.  So we're sort of now at a point where we have, and really a  lot of this is being done under the banner of system D, we  have for the first time something that people  actually feel good about.  And that is good.  And I think that it's going to be around for a while.  So when BSC people ask me, well, we did the Hal thing.  And then you guys, like, ripped the carpet out under us.  Are you going to do the same thing with system D?  I don't think so.  I think system D is here for a while.  So basic stuff about just what I think anybody who's  interested in any kind of large software project porting it  to BSD is get upstream.  If you're maintaining patches in the port's tree, you're  probably doing something wrong.  But not always.  Because get upstream first.  This is something that I've been involved in Ubuntu for a  long time.  And Ubuntu is definitely a project that has an  interesting history with the GNOME project as well.  It hasn't always been friendly.  But we sort of developed a certain protocol of what is  considered good behavior for interacting with upstream  projects.  And upstream first is basically the number one  principle.  If you've got a problem and you need to fix that with a  patch, you're fine.  But you need to fix that with a patch.  Your first step should be getting that patch upstream.  Where the first comes in is that, OK, so you sent it  upstream, and now they're ignoring you because the  maintainer is busy or whatever.  By all means, put that in the port's tree as a patch  against the package.  But when you do that, make sure at the top of it, as a  description, as part of it, provide a link to the bug.  Explain why it's needed.  And maybe even give them a week to see if they can get it  in.  Maybe they change it a little to make it a little bit  better in some way that only they would know how to do  because it's their project.  You get a better patch by doing that.  So I'm kind of getting to the end of the main  thesis of this thing.  So I'm just going to throw on a bunch of points here.  I kind of thought the audience would be a bit bigger.  I have to admit.  My wish list items for things that could be better in  DSD.  Getting this stuff implemented would be really nice.  I baptized.  Yeah, KQ64 would be good, mostly because it would let us  set KQ events for absolute monotonic time with  microsecond or nanosecond accuracy.  Because if you only have 32-bit counters and you want  microsecond or nanosecond accuracy against the  monotonic time, that stops working after some number of  days of uptime.  So you basically need the 64-bit for that.  Yeah, this sucks.  Please, some kind of a file notification API would be good.  It does not suck.  It's not done for what you want.  So we need something new along with it.  It sucks that I have to use this.  Yeah, that's it.  Yeah.  But on that topic, if we could make this a little bit  better, I would ask for the implementation of this.  Which is something.  Yeah, this macOS has this.  And it makes a Filt Vnode slightly less horrible.  Basically, you can open a file like this, just like  Oread Only or Oread Write, you say OEVT only.  And you can't do anything with the file except stick it in  a KQ.  And then you get notifications about changes.  And the biggest difference there is that you can actually  unmount the file system that you did this on.  So we can watch for files on removable media.  Yeah, because right now we have to pull, basically.  So that would be good.  Get on the recording.  If that said that, it would be easy to do.  Yeah.  So Baptiste says that this will be very easy to implement.  And he plans on doing it next week.  No.  No?  Tonight?  Oh, even better.  Just some miscellaneous stuff.  Some of it's on that web page.  LibTool is still setting our path in inappropriate ways on  BSD.  It would be cool if it could stop doing that.  But it just takes that to the lower end.  So you stopped installing LA files for the most part.  You're not installing LA files most of the time, or if you  install them, they are empty?  But our path is still getting set, which is annoying.  I think we changed that.  OK.  Just to check.  But the appropriate way.  Yeah.  Well, if you look in your JH build install directory, just  look on the libraries and see if they have an R path.  And if they don't, then it's good.  But if they do, and I think that they do.  This is another huge one.  As I said, what we consider an API is often the package  config file.  And there's a lot of things in the base system in BSD that  implement APIs that we would expect have package config  files, and they don't.  So we have to hack, configure arguments in order to get  them registered.  Yeah, but usually some of those, because I think  I listen to help, not in really yet.  But I think we are managing all the missing PC files.  So basically, LibRKai, everything which is  things like ZLib and stuff.  OK, that's good.  I see MA and stuff like this.  Is it?  Sorry?  Except here.  Open as a no-suit.  I'll open it, though.  We don't have the  And since you're working on, what's the one you're working  on tonight?  You're working on the OEVT only tonight.  So tomorrow night, you have to work on this one.  That'd be really cool.  If I could ask, which package do I have to install in order  to get this file on my system?  This one, we have it in the total is for Y, and it's not  implemented for one written write note, because the database  would be too huge.  So the idea is to go through the A-V-T way and having a  separate database so that you can have an  accurate amount of A-V-T file.  Actually, package repo does.  Is I really able to create that, just a matter of  instrumenting that all the stuff in the hood is already  available somewhere?  Yeah, so this would help a lot, because JHBuild has a  feature called SysSteps.  And as I said, GNOME has a ton of dependencies.  And maybe you saw at the start of that wiki page, it said,  type PKG install this.  And JHBuild is actually able to figure out that itself if it  has some way of saying which package provides this file.  So that'd be cool.  And here's one I just turned in.  That's pretty funny.  You have this libg-aum in FreeDSD.  And most functions in it are a g-aum underscore.  Some are gctl underscore, and some are g underscore.  And there's another popular library that  also uses g underscore.  And yeah, we both have this symbol.  So no GNOME program can look against libg-aum, which is a  problem for gtop.  So in some ways, I kind of wanted to start a conversation.  I'm pretty much done with the slides now.  If anybody wants to talk about experience they've had, or  like, I approach the GNOME developer once and this  happened, and can you help me out with this, that'd be  pretty cool.  I just like the idea that it sounds like the project  initially didn't really.  I mean, there's tradition in rivalry between projects, but  it's usually over the long run.  It's usually a sibling rivalry, where they're really  involved in the long run.  Yeah, like GNOME, Katie, or whatever.  Yeah.  Yeah.  But I like the idea that once they found there was  valuable information in the form of PRs, or bug reports, in  that case, from another project, it probably didn't  matter to them what other project it was, as long as the  information was valuable.  And it's like, hey, it turns out they're our friends.  Yeah, and my approach to that has always been, well, at  least my new approach since a couple of years ago when I  decided, let's make everybody happy thing just  isn't working anymore.  If somebody's willing to show up and do it regularly, and  it's certainly if it's going to improve my code quality, by  all means.  And if I've done something that's Linux specific, and  there's a better POSIX equivalent, and there's  nothing worse about it, then by all means I'm happy to use  that one.  And I think almost anybody would do this.  We get things like, oh, you're assuming a bash feature in  DNSH, you can't do that.  Everybody's happy to fix those kinds of bugs.  Right, but I think there are a lot of people who think that,  oh, there another project, they're not going to want our  input anyway.  Yeah, that's absolutely.  Right, but I think that is a common misperception that  should be directed.  Yeah, and if.  I mean, Linux said openly that he didn't care about anything  from the bottom of his head.  So, Leonard, yeah.  That's not entirely true.  He said that he didn't care.  He doesn't want to implement compatibility  in such a system for that, but it makes sense, because it's  mainly some of this stuff.  I mean, our init doesn't have any compatibility with  something else.  The problem after that is a stock of what system it does.  All of these parts couldn't be portable.  But the reason why they don't want to get any patches from  the BSD makes, in my opinion, sense, because we don't want  Linux patches in our init.  To tell you the truth, having talked to Leonard a lot on  this topic, he is actually actively anti-BSD.  He is one of the few people I know who I would actually say.  He wishes that all of the BSDs would just die so that  everybody focuses on Linux instead.  But he is the only one I know, like the singular person I  know that has this extreme attitude on the topic.  So some of the CIO might think he would almost like this.  Maybe you could use the BST gap.  No, I don't think he would come.  I don't think he would come.  Bastion, I think we have this Ganomo-S idea, which is we  want to build this whole operating system, start from  Linux and all this stuff all the way up.  And Ganomo-S to different people means a lot of  different things.  And one thing it was was this continuous integration.  We would build this image for virtual machines that we could  test and do it every day.  Actually, we do it on every commit.  And this is a part of what that was.  But what it mostly was, in my opinion, is just a list of  things that you have to have in your system in order for it  to be considered a Ganomo-S.  This has to work properly.  This has to work properly.  We need this.  And I would say that free BSD doesn't meet those criteria,  but only because you don't have things like network manager.  And if you got all of these things and it was working at  the same level, I wouldn't necessarily say that this couldn't  be Ganomo-S in the same sense, even.  One of the things I really like to see the GNOME project do  is when they rely on something which is not directly  GNOME project like Logizy or network manager or whatever,  that they do actually list the actual API from it they  rely on so that if we are to create some kind of wrapper  on top of our own libraries and provide the same API, we can  have at least the first level of subset API we need to do.  And probably later, some people will be improving it.  But having this list, I mean, following it, for example, I'm  not sure.  I think you don't rely on that many API.  Yeah, so this is a conversation I've had with the  SystemD guys a couple of times.  And in fact, that one rejected patch that was on my Wiki  page is basically this.  And this goes back to what I was saying that, for me, an API  is a package config file.  And saying that, OK, you implement this API and you  provide this package config file, but it only implements a  subset of the APIs, to me, that's never going to cut it.  I don't like that.  What I would rather, and that's what this bug was about, is  if there's something like Logindy that has a whole bunch  of things in one API, a lot of them not related to one  another, well, then really maybe that's three APIs.  And we're talking D-Bus there, so it doesn't make as much  sense.  But in this case, it was Udev.  And you had all the Udev APIs.  And then separately, you had this hwdb thing where you could  look up PCI IDs and stuff like that.  And this was all grouped together under a single API,  one package config file.  And we wanted to just use the hardware dblookup, which in no  way depended on anything in the kernel.  It was basically a hash table lookup in a database file.  There's no reason that couldn't have been separate.  And having that as a separate package fig and therefore a  separate API, in my opinion, is something I wanted.  Yeah, but what I mean by that is we have started for Xorg  and we're going to extend it for a lot of things, a project  libdev queue, which current devices basically.  So the idea is to provide an equivalent high-level API that  you can get through Udev or Udev like stuff.  And if you want to do a priority on what kind of  query you want to do first, then if you have a list of what  you expect from Udev extracting the Wikipedia or  whatever, then we know that probably the priority is to  how concurrent this kind of hardware or this kind of  hardware events for this kind of stuff.  And so that we can have something which is good  enough for node to be able to use along with.  But is your intent to provide like a Udev API or to provide  an equivalent API?  Well, the goal of the Dvd queue is to have to provide  their own API and back end for basically anything.  So the goal is to be able to unify all non-vinducts of  writing systems that right now doesn't have a Udev API.  They want to get just plug into our version of the same kind  of primary so that if you don't know, you just have to.  Yeah, so in my opinion, this is unacceptable, in fact.  I don't want a situation where normal applications are  expected to deal with one API or another.  This is really a good backend that you have on the  hour library.  Something that I think would be far more likely, and  people would find to be more acceptable, is that we put  something in GIO, for example, which wraps both of them and  provides an even higher level and nicely  geobjectified API.  And we deal with the abstraction in GLib.  Because I really don't consider it in any way  appropriate that normal applications should  have to do this.  Yeah, the truth is to me.  But anyway, I need to know what GIO in that case would  expect from the operating system.  So that when I'm on my library, I know that my  priority is on this, this, this.  This is cool, but no one needs this stuff for  portability yet.  Yeah, and that's something that I wanted to work on.  It's something that's on the wakey page, is something we  should get this.  But it's not something that I personally have a lot of time  to work on right now.  I got pulled into a lot of stuff like with application  confinement stuff, which is pretty interesting work too.  But if somebody wanted to undertake a project of  making a high level wrapper in GIO that would wrap Udev and  also equally well wrap whatever BSD API is going to be  forthcoming, that would be a project I'd be very much  interested in.  And that's the kind of thing that GNOME people would even  like, because Udev, it gets the job done.  It's not a great API, right?  So if they could have a nicer API that's easier for them to  use and be more portable at the same time, that's just a  win for everybody.  Yeah, because we just cannot create the Udev API because  it exposes some internal links.  Yeah, insert weird string here.  So there's all the system stuff which is exposed, and we  can't explore the same thing.  So you will need it.  If you want probably to do this on the BSD, you will need  anyway to get your abstraction on GD for that.  Yeah, as far as I see it, that would be pretty much the only  acceptable way forward for GNOME.  Having any application if deaf or whatever would not be good.  For us, it even better because even things which are  relying on GD, but not GNOME, we can just talk to them and  say, use your abstraction.  We know that we just have to focus on GD to get the  portability.  Yeah, so if anybody wanted to work on this kind of thing, I'd  really be happy to mentor this project and say, OK, this is  what I think the API should look like, and then go and do it.  I'd be happy about that.  Could it be a sub-ref course for the next year?  Yeah, it could be.  And again, for LoginD, there's a lot of APIs in LoginD that  we need to use.  But again, it's only a subset of some of them.  And exposing that subset in a nice way through G object  could also be something that's appealing.  Although LoginD has a pretty decent API already.  But there are some things like it makes you deal directly  with file descriptors for the suspense stuff, and probably  most people would rather deal with the G object instead,  for example.  Cool.  Thank you for coming.  Oh, sorry.  Yeah.  Have you Germany thoughts on the different file system  event notification APIs that exist?  Have they're?  Yeah, Apple does it best, I think.  Even I Notify is pretty crappy.  I hate I Notify.  But even I Notify is like a world better than what is  available in previous data.  Yeah, so we're looking at, on behalf of the database  accrediting world, looking at a fund project to handle  something like I Notify.  Yeah, I hear there is an idea that instead of queuing up  an FD inside of KQ, you could tell it about an I node  instead, right?  Well, there's a whole bunch of different ideas,  but I'm just curious if we're trying to figure out  what the best method for it would be.  And an option on the table is we'll make an FS events  compatible database.  Yeah, FS events is good for most high level things, I'd say.  But it doesn't work the way that we kind of have our API  working in Glib, in fact.  It's more like what changed since where Glib is more about  online all the time.  And it's not interested in something that happened when  the system was down, because the API just  doesn't expose this concept.  I'd say if I were to tell you the things that I don't like  about I Notify, for example, one of them would be that it's  extremely difficult to know which file I'm actually  monitoring.  Because if you imagine, I think about race conditions a lot.  And if I imagine I have somebody basically actively  attacking my algorithm to monitor files, I could imagine  I get into a situation where I have a bunch of files being  renamed.  I notify a file named A, which then gets renamed out  from under me.  And then I stat the file.  And even if I stat the file on both sides of telling I  Notify, watch that file, I could think that I'm monitoring an  I node that's different from the one that I Notify actually  caught.  And that disturbs me a lot.  And then it's moved.  And now I don't know, OK, so it's moved.  So the thing that I think I'm watching is not actually the  thing that I'm watching.  So you get into situations where you have to watch the parent  directory to make sure that no moves occurred on it.  And then you have to watch a parent directory, parent  directory.  This is a bit of a mess.  I mean, in a certain sense, the KQ thing's a little bit  better that way, because at least I have the FD in hand.  And then I can put that in KQ, and I can F stat the FD.  So at least I know that it's the same thing.  So that's a little bit nice, I guess.  But without EVT only, having that FD open is also a risk.  Because even if I only have it open for a millisecond, if  somebody tries to unmount that file system at that exact  point, it's not going to wait for me to close it.  It's just going to tell them, no, I can't.  And that's a problem, too.  Yeah.  OK.  Yeah.  Yeah, file system notification is something I thought a  bit about.  Maybe we could talk about that after.  Sure.  OK, thank you.  Thank you all for coming.
a_stitch_in_time__jhbuild_0_1307.png a_stitch_in_time__jhbuild_1308_5567.png a_stitch_in_time__jhbuild_5568_6407.png a_stitch_in_time__jhbuild_6408_6755.png a_stitch_in_time__jhbuild_6756_7535.png a_stitch_in_time__jhbuild_7536_8243.png a_stitch_in_time__jhbuild_8244_8315.png a_stitch_in_time__jhbuild_8316_12371.png a_stitch_in_time__jhbuild_12372_15059.png a_stitch_in_time__jhbuild_15060_16739.png a_stitch_in_time__jhbuild_16740_17027.png a_stitch_in_time__jhbuild_17028_18119.png a_stitch_in_time__jhbuild_18120_20171.png a_stitch_in_time__jhbuild_20172_20459.png a_stitch_in_time__jhbuild_20460_20567.png a_stitch_in_time__jhbuild_20568_20651.png a_stitch_in_time__jhbuild_20652_20807.png a_stitch_in_time__jhbuild_20808_21503.png a_stitch_in_time__jhbuild_21504_21575.png a_stitch_in_time__jhbuild_21576_21851.png a_stitch_in_time__jhbuild_21852_22031.png a_stitch_in_time__jhbuild_22032_22787.png a_stitch_in_time__jhbuild_22788_22955.png a_stitch_in_time__jhbuild_22956_23123.png a_stitch_in_time__jhbuild_23124_23243.png a_stitch_in_time__jhbuild_23244_23639.png a_stitch_in_time__jhbuild_23640_24143.png a_stitch_in_time__jhbuild_24144_24443.png a_stitch_in_time__jhbuild_24444_25451.png a_stitch_in_time__jhbuild_25452_26351.png a_stitch_in_time__jhbuild_26352_26639.png a_stitch_in_time__jhbuild_26640_27347.png a_stitch_in_time__jhbuild_27348_27503.png a_stitch_in_time__jhbuild_27504_27863.png a_stitch_in_time__jhbuild_27864_30299.png a_stitch_in_time__jhbuild_30300_30359.png a_stitch_in_time__jhbuild_30360_30515.png a_stitch_in_time__jhbuild_30516_30935.png a_stitch_in_time__jhbuild_30936_32795.png a_stitch_in_time__jhbuild_32796_33863.png a_stitch_in_time__jhbuild_33864_34427.png a_stitch_in_time__jhbuild_34428_34535.png a_stitch_in_time__jhbuild_34536_34847.png a_stitch_in_time__jhbuild_34848_35207.png a_stitch_in_time__jhbuild_35208_35291.png a_stitch_in_time__jhbuild_35292_35363.png a_stitch_in_time__jhbuild_35364_35495.png a_stitch_in_time__jhbuild_35496_36983.png a_stitch_in_time__jhbuild_36984_37343.png a_stitch_in_time__jhbuild_37344_39263.png a_stitch_in_time__jhbuild_39264_39515.png a_stitch_in_time__jhbuild_39516_39623.png a_stitch_in_time__jhbuild_39624_40331.png a_stitch_in_time__jhbuild_40332_60215.png
Can you just introduce yourself? Oh, yeah. OK. So I'm Ryan Lorti. I'm a member of the GNOME project for a long time. And a small while ago undertook improving the relationships of GNOME and FreeBSD. So yeah, I guess that's the introduction, in fact. So I noticed that there were two big problems. And I was sort of approaching it from the problem that GNOME had. But there was also a problem in FreeBSD, which was that GNOME on FreeBSD was not happy. There was version two in the ports. Like version three came out. And it was many, many years. And there was still version two in there. And it was kind of a bad situation, because GNOME is big and unwieldy, and it tends to touch a lot of things. And every time a new version came out, it would be like, OK, what's broken now? OK, well, everything's broken. So we've got to file a bunch of bugs, get it fixed upstream. Hopefully, it'll be fixed in the next version. OK, great, it's fixed. But now a whole bunch of other stuff is broken. And this was just because if you're doing something only once every six months or even sometimes longer, it's not fast enough to catch the problems as they're happening. On the other side, I maintain G-Lib, which is sort of like the base library of GNOME. And it's kind of a mess when it comes to portability. We have so much stacks of if def code around certain things like stat and stat VFS and stat FS. And just basic stuff like, how do I figure out how many free blocks there are in this file system? There are about eight different ways of doing this, depending on the operating system you're on, like old versions of Solaris and stuff. I don't even know how much of that code we use. This is a problem for me, because I kind of want to rip it out. And I'm kind of wondering, well, if I rip it out, is somebody going to get angry at me? Am I going to get hate mail? I don't know. So wouldn't it be nice if we had an actual set of supported systems that we knew that we supported, and we had a way of testing those systems? So we sort of decided in G-Lib. And if G-Lib does something and says, this is the way it is, it's pretty much affecting all of GNOME, because you need G-Lib to run GNOME. So we said, we're going to move away from this idea that we theoretically support anyone who wants to come to us. And we're going to try and nail down more concretely. An idea of we support these platforms, because we care about them, and we know we support them because we actually tested it. It's not just theoretical, hey, somebody sent me a patch a long time ago. Maybe it's still working. It's something that we're testing regularly. So we have a list of platforms that we actually target. And we actually do test regularly on most of them. And we've gotten a little bit better about saying no to people who just show up with one-time patches for obscure operating systems, unless they can commit that they're going to stay around and keep updating that. Yeah? What is the list long? Can you tell us what else is on it for the list of systems? Yeah. That's what it looks like. These are sort of like our first class candidates here. They're the ones that are really getting done on basically a daily basis. These are the ones that we support, but it's not as good. And we would prefer if people could do more stuff about that. Yeah, so that's it. OK, thank you. And we also have tool chain requirements, where we say your compiler must support these features as well, even if they're not necessarily mandated by POSIX. And that page I just flashed up really goes into details about why we chose this approach. And one of the things that that page mentions is that you can't build something like an O on top of POSIX. You just can't do it. I mean, POSIX is great. I love it. It's very well-written. It tends not to be too ambiguous. You get a very good idea of what you're allowed to do by POSIX, but it's simply not enough. Really simple things like power management, completely silent on this topic. How do I change the system time zone? I don't know. Left to the vendor to decide. POSIX is really minimal. We need more than that. And what I was saying before, you can talk about, OK, we're adhering to POSIX, so it should work on all systems. But in practice, that doesn't work either. Because there's always something that, even if you think you followed the spec, you actually didn't. And you're using some specific behavior that is only on Linux or something. And you don't know that when you run it on other systems, even if they are POSIX compliant, that it's going to break horribly. And unless you're actually testing on those systems, you're never going to find out about that. And that brings me to an important point, which is that nobody in GNOME like hates FreeBSD or any of the BSDs. There's this idea going around that it's really true. But it's not. I mean, some people are like BSD friendly. Some people couldn't give a damn, I think, is probably a good way of describing it. Just like, OK, whatever, you're over there. But nobody is actively hostile. And even like the people who don't really care, if you show up with patches in hand, they're generally pretty good about applying them. It really is just a matter of we make mistakes. What can we do? We all are running Linux in GNOME for the most part. When we write code, occasionally we depend on a feature. We don't realize this is in POSIX. Honest mistake. And it's really good. And we appreciate it if people are calling us out on this stuff. But there is another kind of issue, which the stuff I was saying about stuff that's not in POSIX. In GNOME, we have this approach where we call it draining the swamp. And basically, it's, OK, everything's crap. We need to build some feature. We can't do it with what we have here. So we need to plumb through the whole platform layer in order to get what we want. And that often means that we're writing new stuff, like things like systemD, in fact, coming originally from someone quite involved in the GNOME project. And these things are doing useful stuff for us, like what I mentioned before about an API for changing the time zone or the date and time or changing the host name or stuff like this. Before in GNOME, these were parts of GNOME. And they were done in system-dependent ways in this weird back end with lots of FDF that nobody ever looked at. And it was running as root. And we're happy not to have that in our code if we can depend on a feature that's provided by the operating system. So why it's interesting for me to focus on the BSDs a little bit more is because from the standpoint of GLib, sure, we have to support Windows and Mac and all that. But GNOME itself doesn't target Windows and Mac. So if not operating systems like BSD, GNOME as a desktop is basically a Linux-only affair. So having another platform that we can target is quite useful for us in terms of going from it's theoretically portable to it's actually portable. And even just having just one like pre-BSD, for example, you find really a lot of the portability issues just because there's a different compiler. So I mean, Clang and GCC kind of in some ways are the same compiler because they support all the same features. But you do find a lot more bugs just by having one other C compiler. And then after that one extra, you get maybe three C compilers, you get diminishing returns here quite quickly. Same with Live-C kernel. Anything else, just having that one extra is going to find really a lot of portability issues because any Linux specific feature, instantly you find out about it. In addition to portability issues, do you find that you improve your code overall by having a hybrid and having it work on more than one compiler? It's an interesting question. Sometimes that's true. It's actually often false. Because so to give an example of something that we recently added support for in GLib, that depends on a GCC feature. And therefore, we cannot use it in GLib itself, there's a thing called a cleanup attribute in GCC, which is phenomenally useful. And it allows you to define an attribute on a local variable that when it goes out of scope, it automatically gets a function called on it that will free it or whatever. This could phenomenally improve our code quality. And we can't use it because we have to be portable, right? We often run into things like this, that if only we had this compiler feature everywhere, we could do this thing that would make our code really a lot more readable, a lot better quality. Yeah. Sometimes you're forced to go to the lowest common denominator. Yeah, and that does hurt code quality often. I mean, you are in a RIA GCC, or is RIA need? And you're the supported compiler because Clam has the cleanup stuff? Yeah. Again, in lots of GNOME projects, use the cleanup stuff. Oh my goodness. Yeah, sorry, I'm giving a talk. Lots of GNOME stuff that only targets Linux and free GSC will use that stuff. But in GLib, we also have to target macOS and Windows. Well, macOS, again, wouldn't be a problem. But we target Visual Studio, so it's a no go. And in theory, if you want to use the Intel compiler, the Sun compiler, that stuff is still supported in GLib. So yeah, we can't rely on that feature, which is unfortunate, and I'd like to. But yeah, often if you try and support multiple systems, it does force you to think in a more abstract way. And sometimes that leads to improvements. But I'd actually argue that honestly, just being able to do it once and do it a certain way is almost always better from the code being cleaner, actually. Fewer abstractions, I think, can actually be a good thing, just because it's less code overall, right? So yeah, so a little more detail about what I was talking about earlier, sort of going back over to the free VSD side of things now. There was GNOME 2 in ports forever after GNOME 3 was released. The uphill battle I was talking about with the new versions, it was hard to stay up to date with that. So a while ago, I approached the GNOME VBSC team and said, hey, there's a single JH build. I think you guys should run it. And what JH build is for those who don't know is it's sort of like a meta build system. GNOME is really very large. It's like if you talk about it and it's closely related external dependencies, you're talking like 160 tar balls, more or less. And building all of those is a bit of a pain. So we have JH build, which does that for us. And it'll go and download, and then it'll configure it, make, make, install. And it does something cool. You can install it in your home directory. And then it'll set up in a bunch of environment variables, like LD library path and all that stuff, so that when you build the next module, which depends on that first one, it can find the include files and the libraries and all that in your home directory. So you can do this without messing up your system. And one of the, yeah, sure. I was just going to ask what JH stands for. James Henstridge. He's the guy that wrote it. OK. Little bit of a history there. He's a cool guy. One of the really cool things about JH build, though, is that it's default mode of operation, is that it takes all of the software out of Git. And it takes it out of Gitmaster. So if you want to know what's in GNOME like today, as of the thing that got committed five minutes ago, you can compile it with JH build and you're going to get that. The reason that's really cool is you can really keep track of any issues that might be sneaking into the code at any given time. And certainly, if we're doing that on FreeBSD, then we get a really good idea of any potential portability issues that are sneaking into the code at any given time, which is wonderful. And this is where that whole Stitch in Time stage nine thing comes in. When you find somebody did a commit that caused a problem, or you find maybe we're doing it once a day, it worked yesterday. It doesn't work today. So maybe there's like 10 commits. Yeah, this looks like the one that caused the problem. I can email that person. It's fresh in their mind. I can file a bug about it. They're probably going to have some idea of what they can do to fix it at that point. Versus if I'm waiting six months or a year later when the release comes, it's not working. Oh, geez. OK, what changed? I don't even know how to track this down. Who's fault it is? Even if I do figure out what commit it is, I go to that person. OK, do you remember this thing you did a year ago? Yeah, it's causing me trouble now. Can you reevaluate that? Well, no, sorry. I'm like, I'm totally something else now. I can't do that for you. So the FreeBSDEGENOME team, Cope has been a big part of this, is basically every day running JH build on FreeBSDE now, at least once a day. And Ting Wei Lan, also another person who's doing this very actively. And when stuff breaks, they're filing bugs upstream right away. And this isn't just portability bugs. I mean, we have continuous builders as well running on Linux in Genome. But sometimes the BSD guys are the first ones who find problems where it's just like, did you actually test this before you committed it? And these bugs are going upstream too. And this has really resulted in a fundamental shift in the relationship, I think, between FreeBSDE and Genome. Because when Genome contributors and Genome hackers and maintainers have really become accustomed to receiving bug reports from FreeBSDE people now. And they're pretty good, in my opinion, about replying to them. We have a Wiki page, actually. I should pull that up. It sort of details everything that's been going on. And as we've done, it's a list of fixed bugs. Yeah, so this page is huge. I mean, you see the scroll bar there. It's really impressive. Like, this is, if you want to get it set up, you've got to do all this stuff. Yeah, these are the outstanding issues in Genome, which is some low priority stuff. But the most impressive thing is like this, are the issues that we've solved. And that goes on. It's just a huge number of patches that were sent upstream and applied by upstream happily for addressing FreeBSDE portability issues. And that list is growing all the time. One patch rejected upstream, which I think is pretty cool. That was a patch against Udev. And I talked to the maintainer about that recently, and he might change his mind. So the response from upstream has been great about that. Yeah, so that's really good. Yeah, as I said, you all saw the list. It's pretty good. And it's just getting bigger. So what do we do? So one of the things I was mentioning is about how POSIX is not good enough for us. So we're doing things like log-in D for power management and stuff, and figuring out which session is the active one. And we're depending on things like Udev for enumerating hardware and all that. And this is my opinion. And it's something that I've talked about with the release team of Genome. And they're sort of on board with this idea. The approach to portability that I like is that you depend on an API, not a particular piece of software in name. And when I say an API, I mean a header file that you include that has a certain set of symbols of a given name in it, or a PC file, a packaging fig, that you link into your project, and again, gets you a certain set of symbols that you can use in the project. So this is for things like, say I wanted to enumerate all the webcams on the system, it would be good if I had just a single PC file that I could include that got me an API that looked a certain way that I could use. And I could do that everywhere. That would be really great for me from the upstream standpoint. As it turns out, we have this. It's Udev on Linux right now. It's not the most portable API. There's nothing stopping people from implementing it, per se, but I can understand why people wouldn't want to, because it's very Linux specific. It's putting stuff from the kernel in there. And other things like the log-in D APIs or the other system D service APIs, I think they're really good APIs. And I wish people would just implement them. And it would never be our intent to depend on system D, for example, but to depend on anyone who's willing to provide these APIs. And in my opinion, that is sort of the best approach to portability. Because for lack of that, I'm basically having to write different back ends to put if-desk in my code and stuff like that. So we do need to depend on more than just POSIX. But in a way, POSIX kind of gives us a good idea about, well, why don't we write a spec for what we expect from the operating system? And then everybody can implement that spec. And one of the cool things about a lot of system D is it has a wiki page where it says, here's the various APIs that we implement in system D. And here are the ones that we think should be reasonably portable to other systems. And by the way, here's where they are documented. And this documentation is firm. And we don't plan on changing the API. And on that topic is, I think system D. I mean, if you look at it, we sort of did Hal and DeviceKit. And we did DevFS we had. We're getting to a place. And I mean, before, as I said, we sort of started out in this damn point of GNOME, we need to do stuff. How do we get this stuff done? It all sucks. What can we really do about it? So we started doing things. And it was kind of at a point where D-Bus was new. We were kind of getting a grasp of how we write good D-Bus services. Hal did what we needed it to do for a while. But it was clearly sort of an experimental foray into this new world. And it wasn't great. And similarly, ConsoleKit, it did what it needed to do, but it wasn't great. So we're sort of now at a point where we have, and really a lot of this is being done under the banner of system D, we have for the first time something that people actually feel good about. And that is good. And I think that it's going to be around for a while. So when BSC people ask me, well, we did the Hal thing. And then you guys, like, ripped the carpet out under us. Are you going to do the same thing with system D? I don't think so. I think system D is here for a while. So basic stuff about just what I think anybody who's interested in any kind of large software project porting it to BSD is get upstream. If you're maintaining patches in the port's tree, you're probably doing something wrong. But not always. Because get upstream first. This is something that I've been involved in Ubuntu for a long time. And Ubuntu is definitely a project that has an interesting history with the GNOME project as well. It hasn't always been friendly. But we sort of developed a certain protocol of what is considered good behavior for interacting with upstream projects. And upstream first is basically the number one principle. If you've got a problem and you need to fix that with a patch, you're fine. But you need to fix that with a patch. Your first step should be getting that patch upstream. Where the first comes in is that, OK, so you sent it upstream, and now they're ignoring you because the maintainer is busy or whatever. By all means, put that in the port's tree as a patch against the package. But when you do that, make sure at the top of it, as a description, as part of it, provide a link to the bug. Explain why it's needed. And maybe even give them a week to see if they can get it in. Maybe they change it a little to make it a little bit better in some way that only they would know how to do because it's their project. You get a better patch by doing that. So I'm kind of getting to the end of the main thesis of this thing. So I'm just going to throw on a bunch of points here. I kind of thought the audience would be a bit bigger. I have to admit. My wish list items for things that could be better in DSD. Getting this stuff implemented would be really nice. I baptized. Yeah, KQ64 would be good, mostly because it would let us set KQ events for absolute monotonic time with microsecond or nanosecond accuracy. Because if you only have 32-bit counters and you want microsecond or nanosecond accuracy against the monotonic time, that stops working after some number of days of uptime. So you basically need the 64-bit for that. Yeah, this sucks. Please, some kind of a file notification API would be good. It does not suck. It's not done for what you want. So we need something new along with it. It sucks that I have to use this. Yeah, that's it. Yeah. But on that topic, if we could make this a little bit better, I would ask for the implementation of this. Which is something. Yeah, this macOS has this. And it makes a Filt Vnode slightly less horrible. Basically, you can open a file like this, just like Oread Only or Oread Write, you say OEVT only. And you can't do anything with the file except stick it in a KQ. And then you get notifications about changes. And the biggest difference there is that you can actually unmount the file system that you did this on. So we can watch for files on removable media. Yeah, because right now we have to pull, basically. So that would be good. Get on the recording. If that said that, it would be easy to do. Yeah. So Baptiste says that this will be very easy to implement. And he plans on doing it next week. No. No? Tonight? Oh, even better. Just some miscellaneous stuff. Some of it's on that web page. LibTool is still setting our path in inappropriate ways on BSD. It would be cool if it could stop doing that. But it just takes that to the lower end. So you stopped installing LA files for the most part. You're not installing LA files most of the time, or if you install them, they are empty? But our path is still getting set, which is annoying. I think we changed that. OK. Just to check. But the appropriate way. Yeah. Well, if you look in your JH build install directory, just look on the libraries and see if they have an R path. And if they don't, then it's good. But if they do, and I think that they do. This is another huge one. As I said, what we consider an API is often the package config file. And there's a lot of things in the base system in BSD that implement APIs that we would expect have package config files, and they don't. So we have to hack, configure arguments in order to get them registered. Yeah, but usually some of those, because I think I listen to help, not in really yet. But I think we are managing all the missing PC files. So basically, LibRKai, everything which is things like ZLib and stuff. OK, that's good. I see MA and stuff like this. Is it? Sorry? Except here. Open as a no-suit. I'll open it, though. We don't have the And since you're working on, what's the one you're working on tonight? You're working on the OEVT only tonight. So tomorrow night, you have to work on this one. That'd be really cool. If I could ask, which package do I have to install in order to get this file on my system? This one, we have it in the total is for Y, and it's not implemented for one written write note, because the database would be too huge. So the idea is to go through the A-V-T way and having a separate database so that you can have an accurate amount of A-V-T file. Actually, package repo does. Is I really able to create that, just a matter of instrumenting that all the stuff in the hood is already available somewhere? Yeah, so this would help a lot, because JHBuild has a feature called SysSteps. And as I said, GNOME has a ton of dependencies. And maybe you saw at the start of that wiki page, it said, type PKG install this. And JHBuild is actually able to figure out that itself if it has some way of saying which package provides this file. So that'd be cool. And here's one I just turned in. That's pretty funny. You have this libg-aum in FreeDSD. And most functions in it are a g-aum underscore. Some are gctl underscore, and some are g underscore. And there's another popular library that also uses g underscore. And yeah, we both have this symbol. So no GNOME program can look against libg-aum, which is a problem for gtop. So in some ways, I kind of wanted to start a conversation. I'm pretty much done with the slides now. If anybody wants to talk about experience they've had, or like, I approach the GNOME developer once and this happened, and can you help me out with this, that'd be pretty cool. I just like the idea that it sounds like the project initially didn't really. I mean, there's tradition in rivalry between projects, but it's usually over the long run. It's usually a sibling rivalry, where they're really involved in the long run. Yeah, like GNOME, Katie, or whatever. Yeah. Yeah. But I like the idea that once they found there was valuable information in the form of PRs, or bug reports, in that case, from another project, it probably didn't matter to them what other project it was, as long as the information was valuable. And it's like, hey, it turns out they're our friends. Yeah, and my approach to that has always been, well, at least my new approach since a couple of years ago when I decided, let's make everybody happy thing just isn't working anymore. If somebody's willing to show up and do it regularly, and it's certainly if it's going to improve my code quality, by all means. And if I've done something that's Linux specific, and there's a better POSIX equivalent, and there's nothing worse about it, then by all means I'm happy to use that one. And I think almost anybody would do this. We get things like, oh, you're assuming a bash feature in DNSH, you can't do that. Everybody's happy to fix those kinds of bugs. Right, but I think there are a lot of people who think that, oh, there another project, they're not going to want our input anyway. Yeah, that's absolutely. Right, but I think that is a common misperception that should be directed. Yeah, and if. I mean, Linux said openly that he didn't care about anything from the bottom of his head. So, Leonard, yeah. That's not entirely true. He said that he didn't care. He doesn't want to implement compatibility in such a system for that, but it makes sense, because it's mainly some of this stuff. I mean, our init doesn't have any compatibility with something else. The problem after that is a stock of what system it does. All of these parts couldn't be portable. But the reason why they don't want to get any patches from the BSD makes, in my opinion, sense, because we don't want Linux patches in our init. To tell you the truth, having talked to Leonard a lot on this topic, he is actually actively anti-BSD. He is one of the few people I know who I would actually say. He wishes that all of the BSDs would just die so that everybody focuses on Linux instead. But he is the only one I know, like the singular person I know that has this extreme attitude on the topic. So some of the CIO might think he would almost like this. Maybe you could use the BST gap. No, I don't think he would come. I don't think he would come. Bastion, I think we have this Ganomo-S idea, which is we want to build this whole operating system, start from Linux and all this stuff all the way up. And Ganomo-S to different people means a lot of different things. And one thing it was was this continuous integration. We would build this image for virtual machines that we could test and do it every day. Actually, we do it on every commit. And this is a part of what that was. But what it mostly was, in my opinion, is just a list of things that you have to have in your system in order for it to be considered a Ganomo-S. This has to work properly. This has to work properly. We need this. And I would say that free BSD doesn't meet those criteria, but only because you don't have things like network manager. And if you got all of these things and it was working at the same level, I wouldn't necessarily say that this couldn't be Ganomo-S in the same sense, even. One of the things I really like to see the GNOME project do is when they rely on something which is not directly GNOME project like Logizy or network manager or whatever, that they do actually list the actual API from it they rely on so that if we are to create some kind of wrapper on top of our own libraries and provide the same API, we can have at least the first level of subset API we need to do. And probably later, some people will be improving it. But having this list, I mean, following it, for example, I'm not sure. I think you don't rely on that many API. Yeah, so this is a conversation I've had with the SystemD guys a couple of times. And in fact, that one rejected patch that was on my Wiki page is basically this. And this goes back to what I was saying that, for me, an API is a package config file. And saying that, OK, you implement this API and you provide this package config file, but it only implements a subset of the APIs, to me, that's never going to cut it. I don't like that. What I would rather, and that's what this bug was about, is if there's something like Logindy that has a whole bunch of things in one API, a lot of them not related to one another, well, then really maybe that's three APIs. And we're talking D-Bus there, so it doesn't make as much sense. But in this case, it was Udev. And you had all the Udev APIs. And then separately, you had this hwdb thing where you could look up PCI IDs and stuff like that. And this was all grouped together under a single API, one package config file. And we wanted to just use the hardware dblookup, which in no way depended on anything in the kernel. It was basically a hash table lookup in a database file. There's no reason that couldn't have been separate. And having that as a separate package fig and therefore a separate API, in my opinion, is something I wanted. Yeah, but what I mean by that is we have started for Xorg and we're going to extend it for a lot of things, a project libdev queue, which current devices basically. So the idea is to provide an equivalent high-level API that you can get through Udev or Udev like stuff. And if you want to do a priority on what kind of query you want to do first, then if you have a list of what you expect from Udev extracting the Wikipedia or whatever, then we know that probably the priority is to how concurrent this kind of hardware or this kind of hardware events for this kind of stuff. And so that we can have something which is good enough for node to be able to use along with. But is your intent to provide like a Udev API or to provide an equivalent API? Well, the goal of the Dvd queue is to have to provide their own API and back end for basically anything. So the goal is to be able to unify all non-vinducts of writing systems that right now doesn't have a Udev API. They want to get just plug into our version of the same kind of primary so that if you don't know, you just have to. Yeah, so in my opinion, this is unacceptable, in fact. I don't want a situation where normal applications are expected to deal with one API or another. This is really a good backend that you have on the hour library. Something that I think would be far more likely, and people would find to be more acceptable, is that we put something in GIO, for example, which wraps both of them and provides an even higher level and nicely geobjectified API. And we deal with the abstraction in GLib. Because I really don't consider it in any way appropriate that normal applications should have to do this. Yeah, the truth is to me. But anyway, I need to know what GIO in that case would expect from the operating system. So that when I'm on my library, I know that my priority is on this, this, this. This is cool, but no one needs this stuff for portability yet. Yeah, and that's something that I wanted to work on. It's something that's on the wakey page, is something we should get this. But it's not something that I personally have a lot of time to work on right now. I got pulled into a lot of stuff like with application confinement stuff, which is pretty interesting work too. But if somebody wanted to undertake a project of making a high level wrapper in GIO that would wrap Udev and also equally well wrap whatever BSD API is going to be forthcoming, that would be a project I'd be very much interested in. And that's the kind of thing that GNOME people would even like, because Udev, it gets the job done. It's not a great API, right? So if they could have a nicer API that's easier for them to use and be more portable at the same time, that's just a win for everybody. Yeah, because we just cannot create the Udev API because it exposes some internal links. Yeah, insert weird string here. So there's all the system stuff which is exposed, and we can't explore the same thing. So you will need it. If you want probably to do this on the BSD, you will need anyway to get your abstraction on GD for that. Yeah, as far as I see it, that would be pretty much the only acceptable way forward for GNOME. Having any application if deaf or whatever would not be good. For us, it even better because even things which are relying on GD, but not GNOME, we can just talk to them and say, use your abstraction. We know that we just have to focus on GD to get the portability. Yeah, so if anybody wanted to work on this kind of thing, I'd really be happy to mentor this project and say, OK, this is what I think the API should look like, and then go and do it. I'd be happy about that. Could it be a sub-ref course for the next year? Yeah, it could be. And again, for LoginD, there's a lot of APIs in LoginD that we need to use. But again, it's only a subset of some of them. And exposing that subset in a nice way through G object could also be something that's appealing. Although LoginD has a pretty decent API already. But there are some things like it makes you deal directly with file descriptors for the suspense stuff, and probably most people would rather deal with the G object instead, for example. Cool. Thank you for coming. Oh, sorry. Yeah. Have you Germany thoughts on the different file system event notification APIs that exist? Have they're? Yeah, Apple does it best, I think. Even I Notify is pretty crappy. I hate I Notify. But even I Notify is like a world better than what is available in previous data. Yeah, so we're looking at, on behalf of the database accrediting world, looking at a fund project to handle something like I Notify. Yeah, I hear there is an idea that instead of queuing up an FD inside of KQ, you could tell it about an I node instead, right? Well, there's a whole bunch of different ideas, but I'm just curious if we're trying to figure out what the best method for it would be. And an option on the table is we'll make an FS events compatible database. Yeah, FS events is good for most high level things, I'd say. But it doesn't work the way that we kind of have our API working in Glib, in fact. It's more like what changed since where Glib is more about online all the time. And it's not interested in something that happened when the system was down, because the API just doesn't expose this concept. I'd say if I were to tell you the things that I don't like about I Notify, for example, one of them would be that it's extremely difficult to know which file I'm actually monitoring. Because if you imagine, I think about race conditions a lot. And if I imagine I have somebody basically actively attacking my algorithm to monitor files, I could imagine I get into a situation where I have a bunch of files being renamed. I notify a file named A, which then gets renamed out from under me. And then I stat the file. And even if I stat the file on both sides of telling I Notify, watch that file, I could think that I'm monitoring an I node that's different from the one that I Notify actually caught. And that disturbs me a lot. And then it's moved. And now I don't know, OK, so it's moved. So the thing that I think I'm watching is not actually the thing that I'm watching. So you get into situations where you have to watch the parent directory to make sure that no moves occurred on it. And then you have to watch a parent directory, parent directory. This is a bit of a mess. I mean, in a certain sense, the KQ thing's a little bit better that way, because at least I have the FD in hand. And then I can put that in KQ, and I can F stat the FD. So at least I know that it's the same thing. So that's a little bit nice, I guess. But without EVT only, having that FD open is also a risk. Because even if I only have it open for a millisecond, if somebody tries to unmount that file system at that exact point, it's not going to wait for me to close it. It's just going to tell them, no, I can't. And that's a problem, too. Yeah. OK. Yeah. Yeah, file system notification is something I thought a bit about. Maybe we could talk about that after. Sure. OK, thank you. Thank you all for coming.
problem in FreeBSD, which was that GNOME on two in there. And it was kind of a bad situation, to touch a lot of things. And every time a new upstream. Hopefully, it'll be fixed in the next six months or even sometimes longer, it's not And it's kind of a mess when it comes to these were parts of GNOME. And they were done in will free it or whatever. This could phenomenally things now. There was GNOME 2 in ports forever is that it takes all of the software out of Git. portability issues that are sneaking into the what changed? I don't even know how to track this of this, is basically every day running JH build builders as well running on Linux in Genome. But relationship, I think, between FreeBSDE and systems. And by the way, here's where they are behavior for interacting with upstream projects. approach to that has always been, well, at least don't want to get any patches from the BSD makes, think he would come. Bastion, I think we have API is going to be forthcoming, that would be a and be more portable at the same time, that's