 So this is more of a traditional talk. What's also traditional is that we're running late already, even after the first talk. Absolutely fine. No, no, that's sort of expected. That's more of the nature of this kind of thing. A lot of the traditional state of the union talk. A big part of that is looking at the results of the Easybooter survey, which we've been doing for a couple of years now. We've got more and more people to join the survey, even though people do need a reminder to fill out the survey. But it's still going up in terms of participants. That's very good. If you want to see the full survey results in raw, like without much interpretation or text around it, they're already in the Easyboot documentation. You can find them in there. You'll see most of them here, but not everything. And of course, in the survey, there is always a bit of bias, like the people who don't like to fill out the survey are not there. So to some extent, we do assume that this gives a good view of the Easyboot community, but we shouldn't assume everything is full. And that actually pops up. All right. So primary profile of people, the biggest part of people are considered as some system administrators. Second biggest group is user support. CIS admins are going up a bit more. Maybe CIS admins were less busy and had time to fill out the survey. I'm not sure. The same question is being asked in the SPAC survey as well. And there it's very, very different. They have a bigger shift towards researchers and scientists and scientific photographers. Here, it's more systems and users support. And that's more because of the nature of the tool. So that's not really unexpected. Types of organization, this is maybe a bit less interesting, it's very non-sexy in terms of trends. So not much going on here. Geographical, mostly in Europe, no surprise. They're too close. Yeah, OK. Let me know if it keeps happening. Yeah, so mostly Europe, no surprise. Again, if you would look at the SPAC results, those would be very different. It would be very US focused. So we ordered two different tools, two different communities in terms of geographical and in terms of the expertise of people in terms of role in the project. How long have people been using EasyBuild? Quite a while. The people who have been using EasyBuild for 10 years and more are starting to pop up. So people seem to be sticking around, even though it depends on how you interpret these results. Kenneth? What is does? The microphone is very, very poor. The one which Ian had beforehand was a lot better. The one you are using is very, very poor. Sorry to jump in, but. And I'll turn off this guy. How does that sound, Simon? Are you picking me up now? Much better, a bit too high. Yeah, sounds good. OK, I'll talk for a while. And if it's not OK, Simon will tell me. This is going to be a little bit OK. I can live with that. So how long have people been using EasyBuild? Yeah, EasyBuild has been around for 10 plus years and that's starting to show. What's interesting here is that you still see a pretty steady influx of new people. So about 20% of the current community based on the survey is new to the community in the last year. So we keep having new people coming in. That's very good. And it's very important to be aware of that as well. Like people are new, people are not fully aware of how things are done in EasyBuild, what our policies are. Maybe they still need a bit of training and so on. So it's important to be aware of this. This also shows a bit here. How do people first learn about EasyBuild? Word of mouth is still the biggest thing. People see a tutorial or hear someone talking about it or get a recommendation. But more and more people, and that's the red line here, the red part in the graph, are picking up EasyBuild on the job. So they're starting a new job. EasyBuild is being used there. So they're being told to also use EasyBuild there. And that's a big part of the influx of new people that we have. OK, so last year was a special year for EasyBuild. EasyBuild was first publicly released in 2012. And we also had the version 1.0 release in November 2012. So of course, we wanted to do something special around that. Also, the community has been growing since we made it public. So we started quite small with these hackathon meetings. And I think at the very first hackathon, we had one person outside the HPC again team that was Fortis, who came to Ghent and had a discussion of where this thing should be going or could be going. And since then, we've been growing. We've been doing hackathons. We've been in new user meetings like this, two of them virtual, not by choice. We've had sessions at IC and SCM and so on. We did have cake at some point as well. It was actually a five-year cake. I cheated a bit and made it a 10-year cake. I'm very bad at Photoshop. I'm sorry. So yeah, this celebration, we didn't want to go unnoticed. So what we did, one thing is introduce a new EasyBuild logo. The old one is on the top left. It looks like a child drew it. It wasn't a child. It was a Belgian person after a couple of years. So it looks a bit maybe unprofessional. So it made sense to us to try and do a better job at that. So that's what the logo on the right has become. There was actually a graphics designer who was involved in this. And there was a lot of back and forth, a lot of iteration. Yeah, yeah, yeah. With the right tools, it could still be done by a child. That's true. But it does have a lot of layers. And it has a good connection with EasyBuild. There are right up on the EasyBuild website as well. The link is there. And that explains a bit about why it looks like the way it looks. And to me, at least it makes sense. We also asked in the survey, how do people like it? The majority seems to be at least OK with it or better. So I think we're quite happy with it. It's very difficult to create a logo that everybody loves. That would be impossible. But I think we did as good of a job as we could. And some people just don't like change, right? So you can never make everybody happy. I also did an EasyBuild into a new decade talk that looked back at the history of EasyBuild, how things came to be, how have we've been going from in-house development to public release. And beyond that, the start of the community, all the features that were developed that we would have never thought of ourselves. So thanks to having a community, EasyBuild has changed and improved a lot. We've learned a lot of things. And we've been looking forward to new challenges like EasyBuild version 5, the Easy Project, and so on. The pictures show a bit the growth of the community. The one on the top is one of the first EasyBuild meetings we had outside of Belgium, which was in Cyprus. Again, Fortis was very much involved with this. He has a boat there. He has friends there. So he wanted to have a meeting there, and it sort of happened. The one at the bottom is the last EasyBuild user meeting we had, the physical one at least in Barcelona, which is now three years ago. So that was 50 plus people. That was quite big. Slides and recording of that are available. So if you want to check that talk, it's all there. Okay, then back to some of the survey results. So one thing that Ian focused on a lot is hardware, but the software part of all of that is very important as well. And not only the software that's actually running, the scientific software, but the environment in which it's running is important as well. The biggest thing there is the operating system. In the EasyBuild community, and I'm sort of treating that as a proxy to the HPC community, which is a big stretch, but there are at least some trends there that probably map over quite well. The biggest OS is anything redhead based. So REL, CentOS, Rocky Linux, Alma Linux, all these things. CentOS 7 is going down, but actually pretty slowly, especially if you know that its end of life is mid next year, there's still about 50% of the EasyBuild community using this as an operating system. So that's quite extensive. I doubt that will go to zero by summer next year. That's just not gonna happen. And this is actually important for us to realize because a lot of the testing we do in EasyBuild in terms of contributions, we're actually doing that in Rocky 8 or REL or CentOS 8. We're not actively testing in CentOS 7 anymore. So that's something we need to be a bit more careful with. At least for the next two years or so, CentOS 7 is still gonna be relevant. We should still care about it. For the people who are transitioning away from CentOS 7, it looks like Rocky 8 or Rocky 9 is the choice that they're going with. Some people have REL 8, REL 9, so the commercial, the more expensive version of that is basically about sticking over. There's very little Alma Linux being picked up in the EasyBuild community. I think that's true for the larger HPC community as well. So next to anything, Red Hat Days, there's older stuff as well. There's Ubuntu, there's Debian. Yeah, Bart already has a question. Yeah, I think so. Okay. Yeah, so apparently CERN has picked Alma Linux as the replacement for CentOS. Yeah. I've heard about that, but they may be, I'm not sure what made them go for Alma rather than Rocky. They did an extensive study and yeah, they did a lot of in-house work on that and they went with Alma in the end. I'm not sure why, but it looks like they're going against Stream here or Stream. Faster updates was one of the aspects, yeah. Good being. Yeah, so CentOS or anything Red Hat based is all over the place. There's other operating systems as well. So the ones on the right are Ubuntu, the stable releases of Ubuntu, 20.04 and 20.204. They're like very tiny, which doesn't mean we shouldn't care about them, but at least our, most of our efforts are geared towards Red Hat based stuff and the sites who are using Ubuntu and some people are here, yeah, like Oka and Alexandra, Yulik as well, John and Fred Hutch. I'm not, I don't want to say you're on your own, but you're, yeah, you're making yourself a bit more difficult than you maybe should. Now you probably have reasons to pick this and we're still going to properly support this and Ubuntu 20.204, there's this issue with the Python packages that get installed in the sub directory. So these OS specific things happen and we'll deal with it some way or another. There's other operating systems as well, which I'm not even mentioning here. Slash, so anything user based, they're sub 5% in the community at least based on the survey. Then somewhat tied to the operating system is the Python versions being used. We're finally seeing Python 2.7 dying. So it's really dropping off a cliff like it should be. So the end of life of Python 2 was actually end of 2020, which is already, let's say two and a half years ago. And now finally people are starting to stop using it. That's very good. So Easy Build has supported running on top of Python 3 since Easy Build 4, which is, I don't know, two years old. And there's a very easy way to switch it to running on top of Python 3 if you haven't installed any operating system. So please do. Running Easy Build on top of Python 2.7 still works, but it's deprecated. You'll get a big fat warning about it. And we're gonna actively stop supporting Python 2 and the upcoming Easy Build 5. Supporting Python 3.6 is still important because that's the default Python and CentOS 8 and anything REL 8 based. We're gonna keep that and probably keep that for a couple of years, whether we like it or not. The community seems to be okay with that. So more and more people are saying, I don't really care if you drop Python 2 support. So right now we're in a quite good state to actually start doing that. And that's probably gonna happen by the end of the year when we have Easy Build 5. And the documentation, it explains you how you can easily switch the EB wrapper script to tell it to use a particular version of Python. So please make sure you're doing that and that you're no longer using Python 2. Then another question in the survey, are you using Easy Build on a top 500 system? That helps us a bit in terms of getting an idea of on which big systems Easy Build is being used. The list is there. I'm not gonna go through all of them. Most of them are not a surprise to us. So we kind of know that those are Easy Build sites. Loomi is definitely the biggest one here. So Kurt gave a talk on that last year and it's gonna give us an update during this meeting as well. Yeah, if we would count in Flops, so in compute power, then Susie is really big in the Easy Build community because of Loomi, yeah. Yeah, but we're not. I mean, yeah, also in Yulik, I think it's still less-based. Is that still the case? Or is it? It's all centers, okay. And Ubuntu, yeah. So what's interesting here, so 25% of people said they are using Easy Build on a top 500 system. That means three quarters of the community is not doing that. It's using Easy Build on smaller systems. And I'm not sure the spec has a question in this in their survey. I think for them, it would be very different. I think the balance between big and small systems there would be very different. So maybe Easy Build caters more to smaller sites. I'm not sure. Processor family, so this ties in with Ian's talk a little bit at least. Skylake is still the king as far as we can tell. It's about 55% of people have at least one Skylake system. What's really funny and painful is that Haswell and Broadwell are still there and 30% of HPC sites is still running Haswell and Broadwell. So it's basically as long as you have the floor space and as long as they can pay for the electricity, they're keeping these things running. Even Sandy Bridge, yeah. So Sandy Bridge is the green line. That's at about, let's say 20%. And there's a box for older. So older than Sandy Bridge, that's the orange line that's now still at around 10%. So people are keeping really ancient systems still running. 10 years, something like that, and they're keeping it going. That's also important for us, right? We don't have to assume everyone has AVX 512. Even assuming AVX2 is already a stretch, at least for some people. So I'm not sure what they are being used for, but that's interesting. Sapphire Rapids, there's a blip there, but nobody basically has it yet, not a surprise. So that's all Intel processors. Then looking at others, non-Intel, of course AMD is a big one here. AMD Rome, so Zen 2 is over 40% currently in the EasyBuild community. Milan is picking up speed very quickly, is now at about a third of the community. So that's looking very interesting. Anything else, so anything non-X86 is pretty much nowhere, at least today. So it's all at 5% or less. So power, you don't have a lot of power users, no surprise there, but also ARM. I was actually expecting this to be picking up a bit quicker. I think that's gonna change a lot with the NVIDIA Grace CPU, which is ARM. That's really gonna change. So let's say two years from now, this graph is gonna look like it's gonna look a lot different, I think. And that's again a concern for EasyBuild. We'll have to actually start testing on ARM CPUs to make sure stuff works and that's gonna complicate our work quite a bit. Risk five is not here yet. There's no risk five capable CPUs. Maybe on a five year horizon, that will change as well. We'll see what happens. Then accelerators, also here, no surprise. NVIDIA is king, about 65% of people have ampere A30 or A100 GPUs. Basically the most powerful GPUs you can get from NVIDIA. Currently that makes sense. The V100, the Voltaus are there for about a half. The people who filled out the survey and that's stagnant. So it's not dropping off. People are keeping those systems. Probably will keep them for a couple of years. Older generations like Pascal are still there about 30%. So they're keeping them. And the coupler ones are really starting to disappear. So they're in terms of energy consumption probably doesn't make sense anymore to keep running those. Anything non-NVIDIA is again, well, that's not on this slide yet. It actually is. I didn't add the graph here, but there was no point. It's so small that it just, it's in the noise. So AMD GPUs again, flop-wise it would be very different. But in terms of number of people who are installing software for AMD GPUs with EasyBuilds, they're like a small blip, one, two, three percent. Typically the bigger size like Lumi and Uligar, but nobody else's. And yeah, the smaller Nvidia GPUs are there that's going up and down a bit. So it depends a bit on what the market is doing and how interesting it is to buy these. All right. Another thing we did in the last year is revamped the EasyBuild documentation. We've been talking about this for a couple of years, maybe two user meetings, possibly three, at least floating the idea. What we wanted to do was migrate our documentation to a Markdown format to the MKDocs tool. Because at least I'm very convinced that that will make contributing to the documentation significantly easier. And I think we're already starting to see that where more people are at least starting to help out with the documentation. Has some very interesting features, a very nice search in the render documentation. As one of them, there's Alder as well. It's very actively developed MKDocs. So they're making enhancements and improvements and new features all the time. And they have a very special open source development model they do sponsorware. Where as a user, you can say, I'm gonna sponsor the project and that gives you preview of the new features coming up and like the sole right to start using these features months ahead of everybody else. They do ask you not to share the code because it's open source. If you give a copy of that code to someone else, they can do the same thing if they're also using MKDocs. And somehow that works. So even though some of these new features or the code for that is leaking into people who are not sponsoring, somehow it still works. So that's a very interesting approach. The effort and all this was started in October 2022 by setting up a dedicated repository for the documentation. Copying all the documentation in the restructure text format in there and then starting to port it gradually onto Markdown. We also moved from read the docs to GitHub pages. So we have everything in GitHub that made a bit more sense. A lot of the porting effort was actually done by Simon. Simon, raise your hand here in front. And James, where's James? James is in the back. If you run into these people this week, buy them a beer or buy them two beers because they've been really doing all the work in terms of porting and in a pretty short amount of time. So that whole effort, including switching docs.easible.io to the new documentation was done in January. What we made very sure of is that we didn't break any existing URLs. So we have a mailing list, we have Slack, we have GitHub, lots of comments in there with pointers to the documentation. All those links should still work, even though we moved to a totally different platform, a totally different tool. So we were very careful not to break those URLs. So this is what it looks like. The one on the left is the old one. Which hurts my eyes currently. The one on the right is the current documentation, the dark view of that, which looks a lot better. The structure is a lot better as well. It's probably way easier to find stuff if you're looking for it, at least I hope it is. And if it's not, we're gonna improve it a lot as we can. The search feature is really good and they're actively working on it in MK docs to even make it better. So you can tag individual pages and more guide people using the search feature to specific pages if you want to. There's a light and a dark mode. I use the dark mode always because that attracts less bugs, but some people do use the light mode. And overall, this seems to be received quite well for the people that have made up their mind or have looked at it enough to form an opinion. It's mostly positive and there's only a very small part that says, I like the old documentation better. They're welcome to help out with the new documentation, of course. Revise the color teams to make them more accessible. Okay, yeah, then there's something we should check for. Not enough contrast in the current, yeah, yeah, yeah. Yeah, okay, yeah, that's very important to... Yeah, yeah, no, that's a very good suggestion. We should keep an eye on that. We've actually done some of that already, but probably not far enough or... And I guess there's tools also that help you, that gives you scoring or gives you, yeah, yeah, yeah. Yeah, okay, yeah, we should look at some of those tools to improve the color scheme, yeah. Okay, so this whole effort is not the end. It's actually only a starting point. At least it is to me. So this was like a necessary evil getting rid of this old format that wasn't really helpful for contributors. That was just the first step. We now want to actively start filling up the gaps in the existing documentation, restructure some of the documentation. Like the writing easy configs page is huge, has way too much detail. It should be at least the landing pages that should be way more basic and point you to other places if you want more specific information. So break it up into smaller pages. We should actually update the documentation when we implement new stuff. We're not doing that often enough. So we are making enhancements, but the people are not using them because they don't know it's there. We've kickstarted a yearly review cycle of the documentation. What we want to do is have someone look at every page looking if it's still up to date, if it has parts that are missing or that are just totally outdated. We found some of them already and actually doing an update of that page. We think with enough helping hands, we can do that in the scope of a year and then keep doing it every year over and over again. The first one is going to be the painful one because we're hitting things that are still claiming they are relevant for easy build two, which has been gone for six, seven years or something. But yeah, I think this is an important thing as well. Yeah, another remark. Can we automate the review cycle? So what we're doing now is we're creating an issue for each page that says this page should be reviewed. If it's reviewed, the issue is closed. The next year we can basically reopen the issue and just keep going like this. So yeah, and to some extent, we can probably automate it as well if you want. Yeah, and that's actually going to my next point. We actually want to engage more contributors for this because this type of work is very different from coding or reviewing easy conflicts, testing easy conflicts. It's more technical writing and really seeing if it makes sense. What is there? Does it make sense? Does it need to be explained better or does it have caps? So we're hoping to attract new people and maybe dedicated documentation maintainers for this type of thing. Next to the current maintainers that we already have. Another thing is we should probably also collapse the EasyBuild tutorial, which is now a totally separate site, but also using MKDocs. You should collapse that into the documentation. So if you're searching the documentation, you're also hitting parts of the tutorial. It's now totally separate and that doesn't really make sense. So if you would like to be involved in that, we have a dedicated docs channel in the EasyBuild Slack. Please join there. We should probably do a semi-regular meeting on the documentation itself as well. Maybe once every two months or something a bit less frequent than the other stuff we have just to check what the big next step is that we could take. There's also the EasyBuild tutorial. Like I said, it's now a totally separate website. We've had an official EasyBuild tutorial at ISC last year, which was pretty much the same setup that we had the year before. The year before that, we did a fully online tutorial because of the pandemic. So that's been going on for a couple of years now. We did a submission for ISC 23, which was not accepted. It's not entirely clear to us why it looks like it was more competitive than previous years. It looks like we got very close to being accepted. But there was one reviewer who was strongly worded enough and gave us a low score enough that we just dropped out. Yeah, they also shrunk the amount of space that's available for tutorials. So there's actually less people. Yeah, yeah. Maybe we're the victim of that. It's not clear. So yeah, if we don't have an ISC tutorial, we're just looking for other opportunities. We're actually doing an easy build plus easy introductory workshop at the end of this week as well, Thursday and Friday, mostly focused on UK sites. So it's a small group and we only have 20 seats. We're not planning to do live streaming of that, but we are gonna try and record it and just make it available through the EasyBuild YouTube channel afterwards. So that's an introduction to EasyBuild. Some advanced topics and then also a half-day introduction to the Easy Project which Kasper will tell us more about tomorrow, I think, yeah. Next to this, we could maybe again do a fully free online EasyBuild tutorial, maybe with a small part on Easy later this year in June around ISC or shortly after that or later in 2023. When we did this in 2020, but 2020 is a bad year to compare with. That was a very interesting year. We had over 100 registrations back then. So by doing it fully online, you can reach a lot of people, of course. So maybe we should just redo that again if we don't get the opportunity to do it at ISC. Are people aware of the EasyBuild community? Most are, but a big portion of them had no idea there was an EasyBuild tutorial. So we should do more to promote it like I'm doing now. And yeah, have people worked through the tutorial, there's a whole variety there of answers. Some people check the recording, some people go purely on the website, which has exercises. So people are not interested or don't think they would learn anything. Yeah, that all makes sense. Then in terms of supported software for EasyBuild, we're about to break the threshold of having 3,000 unique software packages. So without versions supported, that's getting really scary. And that's not counting extensions or Python packages that get installed as a group or on top of something else. So if you combine those, then we have about 5,000 unique software projects that we currently support. And that line keeps going up. And if you check closely, especially the last three releases, it's actually tilting a bit, it's picking up the pace. But there seems to be some AI effect there maybe where more people are starting to produce tools because AI is cool and they're using PyTorch as a dependency or they're depending on something else that uses PyTorch and basically making the stack of dependencies a lot deeper. So we see a lot of that going on. We see requests for new installation for new software being installed all the time coming in. I think it's even half the requests we get are for new software packages, which is getting really scary. Yeah, ciao. How does that compare to SPAC in terms of speed of, I have no idea. Yeah. Yes, yeah. So they do all extensions, count them separately. Yeah, that's something we see in EasyBoard as well. Yeah. So for the people remote, for the people remote in terms of raw numbers, SPAC is about 7,000, it should be compared with the 5,000 we have here. So it's maybe slightly lower. There's actually a paper, I should have mentioned this, there's a research paper from, which was sponsored by the Chan Zuckerberg Foundation, so the Facebook people essentially, which did data mining on research papers and looked at how many software projects they could find. Now it's a language model and it's AI and they're extracting tokens from papers and then creating a list. I think the number they came up with was 40,000 unique software projects. We're not even scratching the surface on that. It's insane. I'm not sure how accurate that number is, but I wouldn't, let's say if it's half that, then we're still only hitting like 20, 25% of all software out there, which is research software. So I'm not talking about other software. So to some extent, that's a bit depressing with all the effort that we're doing. There's still a lot more to come and it's only gonna get worse in the years ahead. So it's becoming more and more easy for scientists to produce software, to publish it through GitHub. There's also pressure to publish their software along with their papers and then other people are more easily picking up on it. So it's just snowballs like that. Yeah, so the comment was Pipeye has 300,000 packages. I'm not sure a lot of those are not gonna be relevant to us, but yeah, in terms of ballpark figures, that's scary. Yeah, so yeah, this is not gonna end anytime soon. New stuff will keep coming in and we'll need a good way of dealing with that. This was a bit interesting and maybe a bit of a surprise. So the question in the survey was, are end users using Easy Build to install software? So users themselves, are they using Easy Build in their own account, maybe on top of what's provided centrally? That's actually seemed to be increasing a lot. So the last year, this was a new question last year. That was about 35%. Now it's over 50%. So our researchers taking things into their own hands more often because we are too slow at reacting to the requests. I'm not sure. And let's see if this keeps coming up, but that looks like an interesting trend. Yeah, on different side. Yeah, it depends on how, maybe it's open for interpretation a bit, but yeah. Yeah, so do we, but then they are using Easy Build to install it in their accounts. That's okay, that counts I think. Yeah, so the comment from Bartos that they're often using Easy Build as a way to let people install stuff themselves that they don't wanna include in the central stack because it's a private installation or special configuration, something like this. And then they are basically producing the easy config and just handing it to the user. That's very similar to what we do. We do a lot of that as well. Safe. And probably the same, yeah. Lumie is also the same in that, yeah. But it's an interesting trend. The Easy Build mailing list, yeah, is still there. So this was also a bit interesting. So more people are passive on the mailing list. They're only reading posts to the extent that stuff is still being posted there. But there's an increasing trend and people that say, I should join. It's like people who are there are passive or not using it. And other people are, oh, I'm not on the mailing list. I should be there. And that's very strange to me. Anyway, the mailing list is still there. It's still active. It's not as active as it was before, but it's still an important communication channel. We should definitely not get rid of it. We should not fully replace it by Slack. I should keep using it. Traffic is going down. There's a big Slack effect there. It's going down quite steeply. Is it gonna disappear at some point? Maybe, but we still have 300 people there who haven't unsubscribed. So Slack has become the main hub of communication. So most people are on there. Only about a third of them are actually actively engaging in discussion. So many people are just either not paying attention or only reading stuff. That's also important to realize. If you ask a question there, two thirds of people are never gonna answer. Because maybe they read the question, but they don't feel like answering at all. And if you combine those two, about a fifth of the, I say, easy book community, but the fifth of the people filling out the survey are not on the mailing list or not on Slack. And that's also again important to realize. Activity and Slack has been going up steadily. We have over 700 people there now. I'm not sure when we're gonna hit a thousand, but I guess that means another form of party. I don't know. I don't know how you do a party in Slack. We can figure it out by then. So if you're not there yet, it's very important to realize that. So if you're not there yet, it's very easy to join. Then looking at other tools that people use in combination with EasyBuild, there's environment modules, which is a hard dependency for EasyBuild still, and that's probably not gonna change anytime soon. Elmott is by far the most popular environment modules tool. Elmott 8 is, Elmott 7 is slowly going down as it should be. The last release of Elmott 7 was, help me out, Simon. 2019, so it's about, let's say three and a half years old. Please stop using it. It probably works fine and the fixes that were added in Elmott 8 or the new features that were implemented there, maybe you don't care about them, but it's not a good idea to keep relying on that. We actually may stop supporting Elmott 7 soon. Simon is gonna really talk about that this afternoon. There's another implementation of an environment tool, environment modules as well, which is fully tickle-based, is basically totally unused in the EasyBuild community. One painful detail there, the version 3.2.something, last release is probably 10 years ago, is still the most popular tickle-based version of the environment modules tool. So compared to Elmott, it's absolutely nowhere. But that may be very specific to the EasyBuild community because Elmott is the default modules tool for EasyBuild. All the tools beyond environment modules, there's a long list, I'm not gonna go through all of them in detail. There's a couple of interesting things here. AppTainer is picking up a lot of speeds, so over 40% of people are using that in combination with EasyBuild to some extent. About a quarter of the people are also using KONDA, so I've never gotten an answer to this, but how do people combine software installed with KONDA and software installed with EasyBuild? You run into lots of trouble, no? So what are they using KONDA for? If anyone knows or if anyone is doing that, I would like to hear your thoughts on that. Yeah, Bart. Yeah, so there's actually a KONDA EasyBlock where you can use EasyBuild to install something using KONDA and then get a module for it. Yeah, so there are things like this that you can do. Okay, so for standalone stuff, it does make sense. Yeah, yeah, yeah. So it does make sense for standalone stuff that you don't want to combine with other things. That does make sense. And if it's there and it works, then why go through the effort of, yeah. Okay, there's also a steady increase of people using CERN VMFS probably to park their software installations on, that makes a lot of sense. That's what's being used in the Easy Project. That's what's being used at, I still want to say Compute Canada, but I should say the Digital Research Alliance, yeah, the other. So that's very interesting that that's increasing and it's a difficult project to understand why you want to use it, but once it clicks, I think it's very easy to be convinced and then start looking into it. There's still a small and stable minority, about 8%, it's been pretty stable over the years that uses both EasyBuild and Spark. And then there's new stuff. I added these because either we have talks about it or because some people ask, there's open on demand, that's about 18% of people using it. Very interesting project, we're also using it again. There's a talk about this tomorrow, I think, by James. And there's the Easy Project as well, which is only 10%, so that's also important to know there's some overlap between Easy and EasyBuild, but it's currently relatively small. So more on Easy, I'm not gonna steal Kaspar's thunder here. He has a dedicated talk on this. The interesting message here, EasyBuild is only a very small part of the Easy Project, but there is quite a bit of overlap between the EasyBuild community and Easy. Currently only about a quarter of the EasyBuild community has hands-on experience with Easy, so the people have actually played with it. That's a reasonably good number, but it could be a lot higher. And one very important detail, but Kaspar will mention this as well, is that there's now a dedicated, there's a funded project, a EuroHPC project, where part of the money is actually being used to make EasyBuild, make Easy, sorry, a project that you can start relying on to make it stable, to make it production ready. EasyBuild releases, the frequency of that has been going down a little bit over the years, but people are way more happy now than they were before. I'm actually not very happy with that. I don't think we're pushing out stuff quickly enough, but everybody else thinks it's okay. So maybe I should be in the same boat. And then contributors, ah, this is I, it's a PDF, it's not gonna work. That's another tradition. I always include this gift of the Microsoft people having a party over God knows what. So contributions to EasyBuild framework, that's going up and down a bit, depending on the type of work we're doing. I could imagine in 2023, it's gonna increase again a bit with EasyBuild 5 that we're currently working on. There was a big peak in 2019 when we did the porting to Python 3. And the good news here is over half of the pull requests being done here are not me or anyone in the HPC, UGAN team. So other maintainers or outside contributors. For EasyBlocks, it's a bit similar. It looks like we've done a lot less work in 2022 in EasyBlocks. I'm not sure why, maybe there was just less stuff to do. But we still do have over 30 unique contributors. That's not shown in the graph, but it's 30 different people working on EasyBlocks. And over 70% of the pull requests there are coming from people outside HPC UGAN team. Or even over a third of that are from people who are not an EasyBuild maintainer and that thing, that's a good sign. For EasyConfix, last year, we were very, very close to breaking the 2,500 pull requests per year, which is huge. So if you count in terms of pull requests for working dates, about 10 pull requests you're getting in that you have to work yourself through. I would say luckily last year, it was a little bit less. We got about 10% less pull requests. There's a couple of factors there. We have a big backlog of open pull requests. I'll show that in a bit. We were quite late with defining the 2022 B tool chain. So we had less pull requests, I think, because of that. There's an easy effect there as well. People were busy with easy, so they had less time to open pull requests, probably. And there's lots of things combined. So I don't think this is something to really worry about. We've been having 2000 pull requests a year for several years now, and that's more than enough to keep us busy. Who are merging those pull requests? So this is more of a maintainer view on the left, at least. So I'm less and less involved in merging pull requests and easy conflict pull requests, which is a good thing because if you look at 2016, for example, I was doing close to 1,500 pull requests by myself, which is absolutely insane. And that's when I really started realizing we needed active maintainers and help from additional people, processing contributions. Things have been improving a lot over the last couple of years. What's not so nice is that we're keeping pull requests, more pull requests open. So the backlog of open pull requests is increasing. A big chunk, I think it's about 15% of pull requests open in 2022 are still open, so haven't been closed or merged. So that's not very good. The graph on the right shows how pull requests are opened. We have GitHub integration in EasyBuild where you can make a pull request straight from the EasyBuild command line. You don't need to run any kit commands. You don't need to click around on GitHub. EasyBuild will do all that for you and basically lowers the bar quite a bit to open a pull request. And to some extent that explains the big increase that we've seen in the last couple of years. This is an overview on the backlog of open easy configs. You can see in 2021, 2022, we haven't really been doing, let's say, a very good job of keeping up with incoming pull requests. So this gives a bit of a wrong view. If you keep in mind that we're getting more than 2000 pull requests a year, currently having 800 pull requests open in total is not that bad, but it's still a lot, right? It's a big number and it does cause some trouble. The good thing is we've been keeping it at around 800 for a while now, a couple of months. It's not increasing further. So at least we're again keeping up with incoming pull requests, but we were not able yet to work away the backlog. So that's something we'll have to work on. Older stuff is less relevant, but these things have to actively be cleaned up and it's a lot of work. I think a part of the reason here is the Easy Project. This is like a negative effect of the Easy Project. Several maintainers were busy with the Easy Project, including myself, and that means there was less time to look at incoming contributions. So that's not okay and we'll need a way to figure it out. Hopefully next year I can show an updated graph where it's going down again in terms of backlog. We'll see if that happens. This is an overview of the number of unique contributors where we've been having over the years. So different people opening pull requests and easy conflicts were now over 380 different people who have opened the pull request for easy conflicts over the year. For framework and easy blocks, it's a lot lower, but it's still good numbers, well over a hundred in both cases. What's interesting here, 50 contributors last year were totally new, had never opened the pull request before to easy build. That's good. There's influx of new people. That also means these people are maybe not familiar yet with the policies that we have in our central easy conflicts repository. So again, you have to keep people informed or you're working with new people and you're processing their contribution. That can be a bit of work. That's also visible here. So this is unique contributors per year. So last year we had over a hundred and well, almost 130 unique, so 130 different people opening a pull request for easy conflicts. That means the maintainers have to talk to more people to process all these contributions, which to some extent means more work. And if you know that 50 of those people are entirely new to the project, that combination basically makes the work of the maintainers a bit more difficult. So yeah, everything combined, it all makes sense, it all adds up. I think I will just, yeah, we need to figure out good ways to deal with that. And the last question, or at least the last question where you get to score something is the overall quality of easy build. People are still very happy with the project. We have one person who's, well, one, maybe two people who said it could be better. That's maybe someone from the SPAC community filling out the survey to see what's going on. But over the years, we haven't had a lot of negative feedback there. Autor of CMake, yeah, it could be as well. Now, there's also a lot of bias here as well, of course. If you really hate easy build, there's just no way you're gonna fill out the survey. So we shouldn't overestimate this. There isn't an option, pretty bad in the survey. Nobody has ever picked that one. So even the SPAC people are maybe a bit friendly to easy build as well. Okay, then goals and challenges, this is very short, it's all on a single slide. We're always short on time to do stuff. We're very bad at planning ahead or seeing by two months we'll get that done. That's very difficult. But I think some of the things we'll have to do in the coming year is catch up on the backlog of easy config PRs and keep up with incoming contributions, not only for easy configs, but also framework, easy blocks. So when people do something very big, very complicated, yeah, keep, stay on top of that essentially. Easy build five is coming up. So we're hoping to release that by the end of the year. There's a lot of information there in Simon's talk, which I'm not gonna spoil. Again, this is a very rough timeline by the end of the year. We'll see if we'll actually make it and maybe three months earlier. I'm not sure, it depends a bit on how much stuff we'll be shoving into that. There's a new feature, easy stack files, which has been around for a while, which has experimental support, which we would really like to stabilize so you can start relying on it and stop changing its behavior. So the reason it's experimental because we want to be able to turn this thing upside down still and totally change the behavior like we did in easy build 4.7. But I think what we have now is pretty okay, works quite well. We just need to trim off the rough edges and then make it stable. There's probably also still a bit of work to be done on easy build and the scope of the easy project. So in easy, we're building in a kind of separate or kind of special build environments where we have our part linking where we're building on top of the compact layer, which means we're, we need to find libraries in a different place where we're filtering a lot of dependencies that are usually installed with easy build. But there we don't want to for different reasons. There's probably things we can improve there quite a bit. Also in terms of testing. And for testing, yeah, like I showed, we'll have to start worrying about REL9 on anything REL9 based. Ubuntu is relevant enough that we should actually be testing there as well. We're still stuck with CentOS 7 probably for another year or two. So we're already testing in different places but that could probably improve quite a bit. So maybe we should be doing that. Different CPUs, ARM is gonna be very hard to ignore very soon. It may already be there. We're already doing some testing there but maybe not enough. And different easy build configurations easy as one of them we should also be testing in. So finding like a good combination of these things maybe we should only be testing with easy on ARM and like a special test environment that combines lots of things. I'm not sure how to organize that but we should probably be doing more of that. Yeah, and that's all I have. And I hope we can do a couple of questions at least. We're slowly going into the coffee break obviously is probably waiting for us. Yeah. Do we have any questions? I'll just, yeah, I'll just repeat. So Ubuntu is important because there's a lot of investments being done in that by AI community or people with lots of GPUs. It puts a lot of effort in to make that shorter. I mean, given the back community and started to invest in Ubuntu in terms of speed and cycling and video is made in there. Yeah, yeah. So when the video is doing a lot of stuff with Ubuntu, it's no bother. Okay, so Ubuntu is something we shouldn't be ignoring because we're going to be missing out on a lot of let's say market share especially of the bigger fish and people who are closely with the video. Yeah, well, we also want to get, we also want to get contributions from people who are very experienced like this. Yeah, so if we don't, if we don't have good support there. Yeah. There's some discussion going on. It's probably difficult to folks for the remote people but we should check that coffee break as well. Does anyone have any other questions? I'll be around the whole week because you can bother me at any time. That's absolutely fine.