 Then here, I have a short comparison with other tools. So I'm covering a couple of them. So SPAC is a software installation tool, or as they call it, a flexible package manager for HPC systems, which you've probably heard about as well. It's part of the Access Scale Computing Project in the US. So it's a very big community as well, maybe even bigger than Easy Builders. It was created by Todd Gamblin at the Lawrence Livermore National Lab in the US. In some sense, it's very similar to Easy Build. It's also implemented in Python. It has a strong focus on performance and HPC, highly configurable, well-documented, generates environment module files. It's a worldwide community. So in many ways, it's similar to Easy Build. But then if you look at it more closely, you will see some differences that are quite different to Easy Build. So this is a quick example of a SPAC installation command, where in this case, the MPI Leaks software package is being installed with version 3.3. And we're telling SPAC here that it should be using MPH version 3.2 and GCC as a compiler version 4.9.3 in this case. So you see all these funny-looking characters are just the SPAC syntax for specifying compiler's dependencies and so on. So this may actually not be the complete list of dependencies that you need for MPI Leaks. There may be more things. And if you don't specify something, SPAC will basically fill in the gaps for you and try to make a smart choice about how to pick versions for all of the dependencies matching what you gave as a requirement. So it's a very different way of working than Easy Build, where you use an easy config file where everything is fixed. So it gives more flexibility than Easy Build does in some sense. So this is, I would say, the major feature in SPAC that it has this support for concretization, which basically is the fill-in-the-blanks mechanism they have. There's lots of other features in SPAC as well, which are not in Easy Build. And the other way around, there's things in Easy Build that you don't have in SPAC, like the GitHub integration or the support we have in Easy Build to send installations as jobs to a Slurm cluster, for example. So whether when you want to make a choice between these tools, make sure you're well informed about what the tools support, what kind of use cases they focus on. And the talk I did recently at FOSDEM that compares SPAC, Easy Build, and actually also Nix, Geeks, and Commna, which I briefly mentioned here as well, could help you there with making a good choice. Then Nix and Geeks. Nix, you have heard in Maxime's talk. So they were using this for the compatibility layer and their software stack. The Geeks is very similar. It's basically the same concept, but with a different programming language for the packages and so on. So both these tools are purely functional package managers, as they call themselves. And they have a very strong focus on the reproducibility of software installations. Even to the point where they do things like resetting the date and time when starting an installation to the first second of January 1, 1970 to make sure that the time stamp doesn't affect the installation if times are included in binary and things like this. So they try to aim for bitwise the reproducibility, which is a very strong, very strong goal. So installations done with Nix and Geeks look very different than they do, certainly with Easy Build. So you end up with an installation directory that looks like this, which has this hash in it, which basically encodes the whole, let's say, the whole specification of the installation. So this version of Firefox is not only 33.1, but it has a particular compiler and configuration and all these things behind it. And this is somehow encoded with this hash. There's a project in the Geeks community to try to get Geeks adopted in the HPC community. So there's this Geeks HPC community. They have been doing very interesting things and have been talking about it a lot at conferences, like FOSDEM. But up until now, I haven't seen any wide adoption of these tools in the HPC community. And then, of course, there's KONDA. So many people have run into KONDA in a good or in a bad way before. So KONDA is a package manager that works in a variety of operating systems and is very popular in the scientific community. The main focus point here, I think, is quick installation of software and ease of use. They want to make it very easy for scientists to install software, just KONDA install name of software, and it figures out the rest by itself for the bigger part of it. And they make the users create KONDA environments, which get a whole bunch of software installed even down to their own Python build or Perl or God knows what. I think even Kuda and things like this get added in there as well. So this is not a very good match for HPC systems for a number of reasons. So first of all, they usually install pre-built generic binaries. So binaries that work no matter the processor they will be run on, which means you may be losing lots of performance if you're not using AVX2 or AVX512 instructions because you're basically not using part of your processors in that case. So you may be losing lots of performance there with a KONDA software installation. And it also doesn't give very good support for multi-user environments. So you can't really use KONDA to do a central software stack that you provide to your users. It's kind of an individual user kind of tool. So as you've seen, many HPCs don't like KONDA because it creates lots of problems as well. And there's lots of stuff by default in the home directory. And unless you're careful, you're basically shooting yourself in the foot as well.