That's hard. Hey guys, so got a review here for you for moonlight now This is a movie that I honestly had no idea really existed I didn't even read up on it before I went saw it a friend of mine suggested it to me I went and saw it with him and in short It's basically boyhood, but about an African-American boy and it's shorter and it means more now I got no gripes really gains boyhood. I thought boyhood was a very ambitious project an interesting idea The only thing is nothing really happens in my opinion make sure Patricia Carcatt's character was really good in it But the main point of the story just I don't know. It's okay. We're watching a real life Moonlight is about an African-American boy nicknamed little and it chronic it basically Chronicles his life through youth teenagehood and then adulthood and I like this film for several reasons one It really shows the it really got you know when films talk about the hardships of living in Florida and low welfare in a drug environment And in just basically a rundown neighborhood this film Took it but didn't really I what I thought is instead of showing it with visuals of the area it showed it with the characters This was mainly shown between little and his mother played by Naomi Harris who did a phenomenal job as his mother just this character who has addicted to drugs and is kind of the manipulator of his life and is this basically this Not this hold this anchor But is something that is rooted in his life and is making an effect on him We also have the guy the black guy from House of cards in here and I when I saw him was like, oh, yeah, he's in this movie He's not a main character, but he is a person who kind of is an influence on little's life Oddly enough considering his character who he is and what he does He is a positive effect sort of on little's life as we progress through the years We see him have these questions about his own sexuality about who he is and his choices in life And this every time Something came up. It was always a hard part. It was always a very Soul crushing if you will sort of scenario and it hurt, but it was so good to watch I was into this movie like admittedly at the first Maybe within the first 20 minutes you're gonna be sitting there going. Why am I watching this and then it's gonna be like Oh And then every moment that passes on all these oh moments You're gonna slowly get more and more invested in these characters And throughout the film I'll admit the soundtrack was Phenomenal had a great mix of this classical music set with all these classic blues tunes And I thought that was an interesting choice considering the The subject matter to use classical music So sort of the origin of music and this the origin of this boy's journey Through figuring out who he is and that's the biggest part about this film Is it's about figuring out who he is to not only other people but to himself And I like this film. It was a great film of self-discovery going through all the hardships of life and all kind of a reflection on african-american communities and Homosexual communities and I really did enjoy this film Admittedly, I don't know if I could watch it again in a while because it is a bit hard It reminds me about a bit of last year's beats of no nation not in the sense of its content, but in the sense of that Hard soul wrenching sort of experience and you need a little bit of time to come back from that But otherwise I did enjoy moonlight. Sure. The beginning was a little slow There were some camera choices that I thought were a little odd Admittedly, I thought that the guy with the focus finder was a bit off his job on sometimes And he the director tried to follow a lot Of the work of the director of creed and fruitville station with Lots of long continuous shots and I have a just in my opinion I think it wasn't done as well There are times where the camera is going around these characters And then he tries to kind of do this interloop and the camera just takes this really weird bend back left and then back on characters Now, you know what? I bet this film didn't have like the most supreme of budget and the thing with doing long continuous takes Is that you have very few you're you have a limited amount of chances to do it So I give this film credit for doing those though because I appreciate those types of scenes I appreciate that type of commitment to these films So in the end, I'm going to give moonlight a six out of seven. It was really good. I enjoyed it I'm going to give it that one less just because of the same reason I did that for beast of no nations Really heart wrenching. It's a dark film. It's going to get to you on the feels level But at the end I actually felt that I I felt happier at the end of this film that I did at the end of beast of no nations So anyway guys, that's all for me. Hope you enjoyed this review Check it out. You probably won't get a lot of time to see it. Um, because it's I don't know. It's very limited But anyways, that's all for me. I'll see you guys later


Welcome everyone. This is the Jenkins user experience special interest group. It's the 21st of June 2023. Thanks for being here. I'll update the attendee list a little later here topics that I've got on the on the list for today. What's happened recently in UI improvements as one topic. And then a reminder for the next LTS baseline, a temporary expansion of the security audits. This one, Vodek Filoni will will lead the discussion on. And then we've got in addition, a topic on keyboard usability from Christina Pizzagali. And I've got a closing topic on end of life for operating systems. Any other topics that need to go on the agenda for today. Okay, then let's get started. So on the recent UI improvements. Thanks to the work of Tim Jacome and Basel Crow prototype JS removal has started and is making great progress. Thanks very, very much Jenkins core has had its uses of prototype already removed. Since Jenkins 2.406, the usage from core of prototype is gone. We continue to ship it so that we retain compatibility, but the usages in core are gone so that we can find it and there is now a an experimental feature that you can disable the use of prototype to see what happens. Thanks to Basel for keeping this plugins tracking sheet up to date. We're seeing good progress there as as we get releases of plugins there are some, you can see the the sort of orange colored bars have a pull request and need to be released needs to be merged and released. The red don't have a pull request so we're welcoming contributions from the community and others to help with the transition off of prototype JS. Okay, so next topic on my list then was, we've got a new UI, new feature coming in the UI from Marcus Vinter of SAP. He's proposed to use a modal dialogue inside the web pages for the delete dialogue. Nice modernization really good feel it's been through the security review it's been through various use reviews so it should be arriving pretty soon. Any questions or concerns there. Okay, next topic then was UI improvement pull request from me on fire chick and here there are several in flight that need that are either ready to merge or need review and further discussion. I'm not sure that there's any of these that I feel like a need to highlight specifically over the other just that we've got these ongoing pull requests that that are looking for comments reviews and getting ready to merge. Then there are some that I'd say have more more discussion going on where it's proposed to change manage Jenkins to be settings. There's a discussion there it's recent discussion happening in the last few days. Good discussion but it needs to continue. Likewise this change of the structure of the, the jelly files to better represent things has good discussion happening between yawn and, and, and Jesse Glick and others. Any questions or concerns on any of those. Okay, then the last item for me on the current current UI progress was, we've got work from Marcus Vinter of SAP on three additional pull requests that are sort of quiet right now and might benefit by some extra attention to bring them back to life. Okay, any other items on specific UI improvements. I did some experiments with the CSS compilation. And I found, I found that I was able to use as able to use some transpiler to compile newer and newer CSS syntax into a form that could still be understood by HTML unit. And I think that could be a viable approach for us to continue to modernize the CSS that we use without breaking our existing unit tests that rely on HTML unit, which can't parse a lot of the newer syntax. So I have one pull request that demonstrates that for the media feature range notation. In general, I think that's an approach that we could use for other CSS features in the future. And we already have the Babel JavaScript transpiler doing the same thing for JavaScript. So this approach should be the same thing but for our style sheets. Thank you. Okay, so, so Basel, in terms of what that really means is as a developer, I can write CSS that's modern, and the transpiler will convert it into a form that is understood by HTML unit three by the old JavaScript interpreter that's that's understood by HTML unit three. Yeah, exactly. In fact, I compared the generated CSS from my change before and after. And it was exactly the same. Even though the code that was checked into get was the newer syntax. So it transpiled to the exact same version as as what we currently have checked into get. Excellent. Now is there is there more review needed there or is it just that we need to we need to get the review and then get it merged. What do you feel like. I think one of them has one approval so far. The other one is for. So I tried to use this transpilation option for that has pseudo notation. And it did not work for that because has is more complicated and cannot be transpiled into older CSS. Without some JavaScript as well so that the polyfill for the has feature is more complicated. It requires both CSS and JavaScript to run in browsers that don't support has and the JavaScript part of this polyfill didn't work in HTML unit either, which is just really just really depressing because you're trying to you're trying to use a polyfill which is ostensibly designed to support older browsers the older browser doesn't even support the polyfill. So, but I think this is more of an exception. I don't think I think in the common case we should be able to transpile most things if they aren't complicated like this, because most of the polyfills that I saw the vast majority of them were pure CSS. There wasn't any, any JavaScript. So, so just because I wasn't able to use the transpile approach in the case of has doesn't mean that we can't use it in general. But getting rid of the has pseudo notation at least makes our logs clean, because our logs are full of HTML unit, not understanding this has notation. Which is just distracting when you're running other tests. So, so basically my first pull request gets simplifies the has the has notation and my my second one introduces the transpiler. Thank you. Thanks very much. Any questions from others to Basel on CSS transpilation on transpiling with CSS. To that, have you tried with some less or CSS situation as well there, or just with pure CSS that is a model. This is, this is already using CSS. The technology that I'm using is, is a, is a preset environment for our for CSS, a building tool, I forget what it's called now post CSS. We were already using scss and the way that this technology works. I thought that I thought that we would be directly compiling scss into CSS, but that's not how it works it. It compiles scss into some intermediary representation that's unique to post CSS. Post CSS has a generic, a generic mechanism for compiling its intermediary representation into CSS. So, essentially, scss and less, and many others are just front ends to this post CSS subsystem, which was surprising to me but that's how it works. Thank you. All right, next, next topic then was the just a reminder from me that as a reminder our next LTS baseline will be chosen in three weeks, July the 12th. So the the weekly releases, we always care about weekly release stability but be mindful that we're up upcoming on the next LTS baseline selection. So, let's do a good job. That likely means 2.414 or 2.413 will be the chosen baseline, if our past patterns hold any questions on LTS baseline selection. Okay Vodek you want to take this next topic. So it's a pretty long topic if you want to move to another one before. No worries for my side. Well, I think I need at least 10 to 20 minutes depending on the discussion around that. Yeah, and I was thinking well, we could we could Christina if you're not especially interested in the security audit we could bring security Christina's earlier. If that would be easier for you Christina or if you intend to be with us the whole time, we'll just put you where where you are on the agenda now, wherever you'd like it. Like, so then, given the time variable this one I'd like to go ahead with this one Vodek if that's okay. No point is not critical that we cover it this week it's just a continuation of what we've already discussed so. To provide you some context related to the topic there you can open the reference that you have like three or four lines after. It just an advisory that we published some days ago, related to an issue that was in Jenkins for perhaps seven years or eight years something like this. So that vulnerability was detected recently by the security team. I think it was one month ago something like this. And what was interesting to see with that one, it was corrected as a side effect of something else. And when you know that it was detected one month ago, but was present for seven years. And it was detected and corrected in the approximately two weeks of this kind of thing that's quite interesting. What's also interesting there is that we are usually doing some audit on the web UI, the pure UI related for request. That was something we put in place some not weeks but month ago, and that reduced drastically the number of vulnerability that were introduced recently in Jenkins. And recently I mean, like, less than one year ago, because we have some vulnerability that we are still finding in the code that are coming from 10 years ago and this kind of thing. It's just a matter of finding them at some point. And with the audit that we are doing, it was reducing drastically the number of them that were recent. So if you come back to the previous or tap please mark. Thank you. So what is interesting there is that that pull request was not UI related. It was in JavaScript with some jelly aspect I don't remember exactly but it's JavaScript and jelly, but these things were not covered by the initial scope of the requirement for the audit in the past, because they are not touching the UI. Meaning it's not visible for the user. That was really the goal of the first policy or instance there. So at this point, that's just for the context, I want to just raise a bit of awareness about the cost of the security release, because that's something that could be oversight by people that are not directly working within that process. So I try to keep it simple there. I discussed with a basil about the extended list of things we are doing. You can see you can see that list is already reduced by at least a factor of two, I think. So we have a lot of costs in terms of time in terms of time frame as well in terms of constraints. I can correct something within the pull request. It's fairly easy. It's a matter of perhaps one day maximum the time to do some ping pong discussion and this kind of thing. But if we wait for it to be released, and part of a version of Jenkins, it's at least 20 times the cost, just for the security team. Now, it's also something to consider it's what is outside of the security team and mentioning that at the end. The preparation is time consuming because we have to do some coordination between what we have ourselves in the private version and what is in the public version. All the backport we have to provide for the weekly and the LTS. In addition, the release lead for the next LTS version will provide some backports. So this backport has to be integrated with our fix and showing that the fix is still fixing the vulnerability. And also the weekly is sometimes something that is changing quickly depending on the time. So we have to integrate that as well inside our fix and still ensuring it's fixing the vulnerability. So due to that, we have to prepare some additional data. So the advisory process, so the content, the description that you are seeing at the end, but also the upgrade guide, the change log, and all the merge information that we are using to do the different merge of the pull request correctly in the good order while ensuring everything is compiling correctly. That's for the security aspect of the security team. What is also invisible most of the time for the contributor is the impact for the user of Jenkins. If you are running a version of Jenkins that has an open vulnerability, meaning that we have published an advisory, your version become vulnerable, openly vulnerable, it was already, but now everybody knows about that. And with the information, some companies has to provide a quick update, so urgent update and this kind of thing, which is disturbing their regular data they work in a sense. So we try to reduce the number of security release to approximately one per month to reduce a bit the alert fatigue, the not have one release every day or every week, it will be a pain for everyone. And also, compared to a non security LTS, if you don't want to adopt a new version of LTS, it's up to you, you don't want a new feature and this kind of thing, that's fine. But when it's a for security, it's expected that you adopt it, because it will have an impact on your instance, or potentially depending on the vulnerability. To point the security scanners, they are very close friends in the sense that they are reporting a lot of CDs, every time that are not always very interesting, but it just a noise that we are adding to the top of all these kind of things. So, all the information there is not to say that we have to split the bill or this kind of thing. It's something that we are paying in the security team, it just to make other people aware about the incurred cost of that. That is not just all you have to correct the thing. It's a one line things you can do it quickly. Yes, the fix itself is simple. Probably it's 95% of the thing. It's outside of the pull request process, the fix. So perhaps any question related to the costs there. So, so have you considered ways to, are there any ways that we could spread those costs or is the reality most of them have to be because of the confidential nature they have to happen inside the security team no matter what. It depends on the people working within this fix. It's more matter of time and will from people. The security team is open. If you want to contribute to participate in this kind of thing. What we usually what we usually require is that the people inside the team are active in the team because they have access to a lot of confidential information. If you are part of the team once per year, it could be problematic in terms of security confidentiality and so on. Providing the fix could be a way to participate in the effort. But as I mentioned, it's 5% of the cost. It's a participation for sure. Typically the release lead and I'm saying in that meeting already some previous release lead. They are participating by the coordination and this kind of thing. So that's also part of the thing there. I'm talking about requiring people who are on the team to be active within the team. And I think there are other teams in Jenkins where it would be beneficial to have a requirement that people who are on the team are active within the team. Agreed. Yeah. Okay, Vadek, do you want me to go on to the next section then. Thank you for the scroll there. So what I'm proposing at this point is that we are expanding the scope of the pull request that require a security review. What is expected at this point is to expand to the jelly and JavaScript pull request, meaning the thing that could be related to same kind of excesses and other vulnerability. I would like to have that expansion to be done for two months and not just indefinite even the previous policies not indefinite in terms of timing it just until we are not single any vulnerability frequently I will say that one it's more like a time box to see if there is an interest if we are finding something because if after two months we have found we have found nothing. There is no value to continue that so to reduce the pace of the development to slow down the contribution that's not the goal. Also, during that period, if we are finding something it's a way also to inform the contributor a be careful that one was dangerous that one could be also impacting in this kind of thing. I will raise a bit triggered some discussion related to that. Also, as I'm explaining the scope of that, I don't want just to be annoying and this kind of thing. We are also helping in terms of compensation there in the sense that currently we are looking actively on the open for request at least once per week. So usually the people in the team are looking at that proactively, but we have one reminder for team per week sorry, and the idea is to move to at least three times per week. Mainly Monday, Wednesday, Friday, this kind of thing. So, if nobody was looking at something on Tuesday, on Wednesday, the team will look at the thing. Okay, we have to split a bit the different things so that we provide an audit as soon as possible. We have to move forward. Something to keep in mind, most of the pull requests that are not UI related are very simple in terms of audit, meaning that we have seen a lot of such pull requests in the past. Reviewing them could take us between five and 10 minutes, something like that. So mainly, if there is something that is blocked because of us, a single ping will solve the situation in perhaps 20 minutes or half an hour. That's very optimistic, I will say. I would like to see the practical effect of that. So, Vada, in terms of how would you like that ping? Is there an alias or just W Follone? What's your preference in terms of if we need to ping? How do we ping? Ideally, the label is enough. The need security review. Oh, good. Okay, add that. Okay, great. And if it's not enough, if we need to have a mention of ping in the pull request, I think we have created a team that is like security review or something like that. I can provide the team name just in two minutes. Also, another point about the scope, why are we doing that only for JavaScript and Jelly, and not for the rest of the pull request like dependency date, backend, correction, modification and so on. It's usually something we have seen. The backend in general in Jenkins is more secure in core and popular plugins. In low popularity plugins, it's also part of the issue, but we are not in that sense of situation. So usually the core maintainer and all the people contributing for the backend. No, I will say 90% of 99% of the thing related to security putting the required post putting the check permission and this kind of thing. So, I have not seen any recent vulnerability introduced because of that. If there were, it's mainly a corner case very complicated code and this kind of thing. So, from my point of view, there is no real risk with that. But the JavaScript Jelly is more easy to put some exercises inside. So that's a bit why I would like to focus on that aspect and not on everything. We have to consider the practical aspect, the team, the security team time is limited. We are not infinite number of people there. So we have to focus on the things that matter the most. That's a bit the idea. And related to that, just a quick reminder. The team is very happy to be pinged on any pull request. Even if it's not gs or jelly, if you think there is something that could be problematic. If you have a doubt fingers. It's a lot easier for us to spend five minutes. Oh, no, no, don't worry. It's a false positive, instead of having to correct something. Basically, I know Alex was thinking us on some of the things. And it was like, oh, no worries. That one is simple. But for us, it's really five minutes. And instead of having something that is very dangerous and is merged. The cost is increased with that. So just a summary about the finger. I hope to have a scope expanded for at least two months. At the end of the two months I expect it to be completed to be removed with the outcome like we have discovered nothing in two months there was no interest to continue at all. Ideally, we have discovered something that are interesting and we have mentioned that to the other people so that they can check by themselves. So that for the future, they will be, I will say, aware we've caught about the different things that are dangerous so that they can ping us more actively without relying on a forced policy like this, which is not ideal at all. So, I'm done with my all liars and these kind of things. So please, any question any concern any feedback about that. So thank you so much for explaining all of this and I really appreciated learning about this process that is followed for each security release. If you want we can explain a bit the discussion, we can spend hours discussing about the whole process and these kind of things. So I know Alexander you've been frequently involved in these kind of pull requests. Are there any concerns from you in terms of this, this extra, this extra step in order to keep security costs reasonable any any concerns from you Alexander. No, I don't have any concerns. One could possibly argue that it would or could slow down the overall time to get a PR delivered. But I don't think the impact is huge on that, given, like what I said, the team would refer them more than one time a week. I don't have that many open pull requests needing attention from the security team targeting jelly or jazz components. So I think the impact would be rather marginal, and we would be still able to deliver front and pull request a timely manner. Great. Thank you. Okay. Are there any others go ahead. Keep in mind that if you are seeing something. Because that's typically something I don't want to slow down the process of others. If we are slowing down by 1% that's fine. But if it become really relevant. We have to discuss we have to readjust the process. Any other concerns any or any concerns from other participants in the call. So then I'm going to go ahead and agreed proceed as as proposed and note, given I've seen no objections I think we we say yes, the UX CIG says let's go ahead with this. Thank you very much for the the Jenkins security team being willing to do it. And thanks to core reviewers for helping helping make it successful. Next topic then was improved keyboard usability Christina do you want to give us a summary there and so where it was left the the big three blockers had been cleared. The top nav sidebar, the bread crumbs. So, in last month's meeting, the ask was that I kind of humanize the breakdown the audit that hadn't done the German language one. So what I've done is created. Let me see. Here I'll just open it. Yeah, please. Yeah, there's seven tasks. The figure rather than bombard the board with a bunch of them group them by the. So right now we're going to target 2.1 keyboard operation and navigation and the results. So some are straightforward some are broken down a bit more so it's got clear acceptance criteria and suggested fixes. But it's a good starting batch. So if I open one of these you're saying that I, okay, there are there is a description of the issue and a link back to the epic so that it's not just experts who could pick this up. No, no, hopefully not. And I assume since I created them if they get comments, I'll, I'll get those. I'll get notified so I can jump in and then provide further clarification if needed. So in terms of is this is this one we've sometimes we get questions in the Gitter channels. I'm a new contributor. I'd like to help. This feels like it's still a little more specialized than a new contributor might be particularly ready to embrace what's your sense is this friendly to a university student or somebody who's just, I would say probably not. Okay, all right. Just because it. It's kind of a core and it's kind of across all. I don't know my gut take would be that, ideally, it was somebody who understood the platform. Okay, so, so that thanks, thanks for the guidance that means for for those of us who sort of do advocacy noise out in the I we're I'm not going to tend to use this one and we'll let this one rather be more handled by people who are already experienced in working in the Jenkins UI. Great. Okay. And most of them are kind of straightforward.  Okay. Thank you any questions from others on on the keyboard usability improvements. Now, I guess this is one these will probably touch jelly files. Right, because that's commonly where, where navigation is set so vodex team will then be flagged, but they should we hope also be relatively simple reviews, because they're not Christina the way you described they're not huge changes. They shouldn't be now. Okay, great. Any other questions for Christina. Okay, next topic then was notifying users of operating system end of life and this is just to share that we've accelerated the visibility of this notification we added an admin monitor in 2.407 to tell people if they were running an operating system we knew would be end of life in the next six months. And we hope that will help at least some subset of them to get off those, those old operating systems. We have an approved exception to the usual LTS policy so that next week when release 2.401.2. And this warning will also appear to LTS users. So that's about eight weeks earlier than we expected. It's not harmful to them. I think it's a reasonable thing to try to warn them earlier that their their operating system is reaching end of life. Any concerns or comments there. I guess I should note one thing is that I'm dreaming of a future extension where where we will warn people about container end of life. And container end of life is a very different thing because it's not the operating system it's the fact that we're no longer going to maintain that container image. That's not there yet it needs extensions to the base thing, but we think it's a good thing to tell people you're running a container image we're not going to support after such and such a date. All right. That's all that I had anything else that we need to discuss here today.


Let's talk about XBPS. XBPS is the package manager that's used on Void Linux. It was actually originally written for it, but it's supposed to be also a portable package manager. You could theoretically use somewhere else. I don't know of any other distros that use it yet, but of course I wanted to do this video because a couple days ago I mentioned that I've been using Void Linux again, and that means a bunch of people are going to be memed into using it themselves. So I'm going to talk about some of the basics about XBPS. How do you install, update, all the basic stuff that you might want to know or might need to know. So anyway, one thing about XBPS. Now, first off, it stands for the X binary package system. And X originally stands, it doesn't stand for Xorg or something like that. It originally stands for Xtreme. I think that's how he pronounces it. That's the guy who actually wrote XBPS and started Void Linux. Now one thing you'll notice is there's no XBPS manual. There is actually no individual XBPS binary, because XBPS is actually a couple of different programs, a constellation of programs that are pretty much related. They're similar in structure, but of course they're different commands. So for example, there is XBPS install. You can probably already guess what this is going to do. There's XBPS remove. There's other stuff like that. And so I'll go ahead and say my gripe, my complaint, which is the most superficial thing in the universe, but it legitimately does annoy me.  So I do recommend people to probably alias all of these. I think most people do, so I alias XI to pseudo XBPS install. That saves me a lot of time, stuff like that. So I alias pretty much all these commands, but that's one minor gripe. Again, it's superficial. It doesn't really matter, but whatever. That's the biggest complaint I have about XBPS, though. So anyway, let's get into how these programs actually work. So first off, how do you install something?  Okay, so GVM, which I don't actually know why I have this installed right now, but let's have something I definitely don't have installed. Emacs, okay? And you can install programs in the same way you expect on any other distribution. So let's talk about some of the options. Now, really, you can run just XBPS on a program, but you're recommended to write capital S. And capital S basically updates the package index just to make sure you're getting the most recent version of this. It's sort of equivalent to Y on Arch Linux on Pac-Man. So XBPS S is probably a more recommended way of doing this just to make sure you're getting the most recent stuff. If you run XBPS U, you don't have to give it any kind of arguments here, but this is update, you know, refresh and update all your packages because S is, you know, syncing the repositories and U is the program or the option that actually updates based on those mirrors or whatever. Now, occasionally, you'll see people run a capital SYU, and I think there are some people, I've talked to some people, some people think, oh, they'll see someone run XBPS install SYU because it looks like Pac-Man SYU and they'll think it's the same thing. It's actually a little different Y on XBPS install and in fact Y on pretty much any XBPS command. That's actually like automatically confirm something or, you know, say yes to any option. So it's not going to prompt you if you want to install it. So that's what Y actually means. Don't get it twisted. It doesn't mean like update repos or something like that. So one interesting thing about XBPS is that you can actually choose where to install particular programs. They have this option R. So you can choose another root directory to install programs in. Let's say, you know, you made some environment that you're going to put on a USB or something. You can actually just use XBPS to, you know, install programs there. There are a couple other options. I'll talk about them as we get into them but that are common among all XBPS commands. Like, for example, V does what you expect on pretty much any program. This shows more verbose output. Anyway, let's talk about uninstalling programs. And for that, you use XBPS Remove. So let's say I want to remove GVM. It will, you don't have to give it any other options and it'll just uninstall GVM. But usually what you want is you want, you know, your program to be uninstalled and all the dependencies that it relies on that you don't need anymore. So you should give XBPS Remove the capital R option and that will get rid of all the other programs that, you know, it uses that nothing else is, you know, using here. So let's actually just as an example, let's run this with Y so we auto-confirm it and also V to give us more verbose output just to see what happens. So you can see that's very verbose and it didn't ask us what we were doing because we gave it V and Y. And of course it uninstalled all of those related programs because we gave it capital R. And again, you can use like lowercase R to uninstall from some other repository that's not your root directory or something like that. Also, you can give, let me actually go back to XBPS Install. Let's say I run SNGVM. N is the option that basically it's a dry run if you just want to see what happens when you run something. N is an option you can give to pretty much any command as well. So there's V for verbose, Y for yes, N for dry run, and R for change your root. But all of those are constant across all XBPS programs pretty much. Anyway, so let's talk about the other command that I think is pretty useful is XBPS Query. I use that a lot. Again, I have it alias to XQ.  So if you just run it, it doesn't do anything by default. But if you give it the L option, for example, that's actually going to list out all of the programs that you have installed on your computer with a description. So you can use that as output for something. Let's actually count out to see how many programs I have installed. 712, okay. Additionally, you can search for remote packages. So let's say I give it the capital R and S options. And this allows us let's look for Emacs-related packages. So everything that has Emacs either in the description or in the name is going to pop up. You could also just give it a kind of a regular expression or glob matching I guess. I think it actually has another reg X option that's more specific. But if we want to see every package, we can just give it an asterisk, which of course has to be escaped because we're passing it as an argument. But if you give it that, it'll actually print out every single package that you can install with XBPS install. So let's actually count those out. I wonder how many there are. Okay, so there are nearly 11,000 packages in Void Linux's repositories right now. Additionally, you can also install other repositories. So I think if you XBPS Void, I want to say, let's probably give it RS. You can actually, so here's the interesting thing about their package system. You can, by default, Void Linux only has free software. And I actually like that. I like that there's a division between free software and non-free software. If you want to install non-free software, you need to install an extra repository. You can see the extra repositories with this command because they all pretty much have Void repo at the beginning.  Let's say you want Chrome or something and you can install that and that is going to allow you to install any other kind of non-free program that happens to be serviced by Void Linux. I really like this divide. I like the ability to install non-free programs if I want, but there is a delineation in the package managing system sort of like on Debian or something like that. And, of course, you'll also see that there's also a multi-lib repository if you want 32-bit packages or something like that or 32-bit and non-free packages. All that kind of stuff is there. So I will go ahead and say something. One thing that xbps doesn't have... Well, they do have it, but it's not exactly the same. One thing you might miss from Arch Linux is the AUR. Now, xbps does have an equivalent called xbps-src. I don't think I have that installed right now. I don't actually use it. I'll go ahead and say first off, Void Linux, in my experience, again, it has 11,000 packages and it's repositories now, even a couple of years ago when I was using it, they always seem to have better stuff than Arch Linux does in their main repos, especially if you watch my channel and you use the kind of programs I use. I've never really been wanting anything in the Void Linux main repositories. Now, they do... You can look up how to get xbps-src. It's sort of an equivalent of the AUR that's actually officially supported by the distribution. It doesn't update... It doesn't update to every commit, basically, so it's not as autistic as, you know, recent, I suppose, as the AUR usually, but it's usually pretty good. I just have no need for it. To say I do install a bunch of programs, but I'll just say Void Linux's repositories, they usually just have everything I need. A couple of the really minor things. I'm going to talk... Let me bring up xbps-remove for a second again. One thing that's really nice about xbps-remove, so you can remove programs with capital R. So let's say I want to uninstall gvm. Okay, it's already done. One other thing you can run is the O option. Basically, it doesn't do anything on my machine, but the O option gets rid of orphaned packages. So let's say, well, let's actually do an example here. Let's install gvm. So it's going to install gvm, and note that it installs two other packages. And let's say when I uninstall gvm, I don't give it the capital R option, meaning those other packages that were installed when I installed gvm, they're still on my machine.  So that will get rid of those packages that were installed with gvm, but not uninstalled with it, because we didn't give it the capital R option. So you can get rid of those, and that's how you get rid of them. Additionally, you can run capital O, excuse me, capital O, and this will get rid of your cached packages. This is like the equivalent of Pac-Man, capital SC, where you get rid of old versions of packages that are still on your computer. So that's a nice thing if you want to clear up your system, or whatever. But I think that's pretty much it. These are the xbps commands that I use pretty much daily, or more or less daily. Again, it's easy to search for packages. It's nice that there's a difference in void Linux between non-free and free packages. You can use xbps-source. I might do a video on that separately on it. And it's generally pretty much the same as Pac-Man. It does all the stuff that Pac-Man can do, but it has some extra features, and really just the only thing I don't like, again, is the fact that all the commands are really long, but you can get over that. You can get over that, but that's about it for this video. Hopefully that's been a good enough introduction, and I'll see you guys next time.