 My name is Michael Bank, and I've been a Debian developer since 2001, I think. And one of my main motivations to become one was that I studied chemistry and there were not a lot of free software packages around back then, and there was almost nothing in Debian itself. There was one guy called Dr. Günther Bechli, I think, who was doing some chemistry and biology stuff. So when I wanted to package my first package, he already packaged it some weeks before. But he gave up half a year later, so he dropped out of Debian and then he had 100 packages. He was the record holder. Back then I wasn't that much involved, so I just noticed that he had packaged one of them. And then I decided to become a Debian developer and also package the chemistry stuff. So generally, what is chemistry? I mean, we're here at Debian.com, so we are between the atoms, that's physics, that's the physics team, I guess, and solids, that's nanoscale physics, which is another team. Chemistry is between very, very small atoms and then when it gets really large in terms of solids or metals or semiconductors and all the molecules in between, that's chemistry. And also, from a more scientific point of view, chemistry is always then when the electrons in the atoms interact with other electrons in other atoms or molecules. And so bonds are broken, bonds are changed. That's where chemistry is. And the other frontier is also biology, so proteins, enzymes, DNA, that kind of stuff. That's biochemistry and then it blends into biology. So as soon as you could say you don't really look at particular molecules anymore but only, oh, we have this DNA base here and we have this DNA base there, then it's probably biology. But if you look at, oh, this DNA base type interacts with some, for some reason with this or that enzyme and you could still model that stuff with chemistry, that interaction. So there it goes to the Debian mate team, which Andreas is doing. So there is a lot of overlap. I mean, not so much in the atom stuff because that's a very clear distinction there. I mean, that's high energy physics or whatever, that's totally different. But as we get to larger systems, there's lots of overlap towards nanoscale physics and Debian mate. And that's why also people are in the same team or interchangeably in the team. So we had also a couple of packages, for example, that the nanoscale physics team said they would package, but it didn't happen so far, so we decided to go ahead and do it now. Also, one could say that chemistry is right on the tech and word divide. So physics was always more of a unix, tech, and that kind of latech environment. So physicists still probably write most of their papers in latech or mathematicians. And chemists actually write most of their papers in Word and they use Windows. And then you have physical chemistry or theoretical chemistry. That's what I did in the end. That's where actually physics and chemistry come together. So maybe 50% of the people in theoretical chemistry are actually physicists and depending on where you come from, you might use tech or you might not. And that's also difficult if you have to interact with other groups writing papers and stuff. So sometimes you get Word papers, sometimes you get tech. And also due to that, there's, I guess, a little slow uptake of free software in chemistry because historically it was used Windows and only some research groups in theoretical chemistry where already it came from physics were using unix. Of course, you see it more, but it really started slow. And also I have to add that theoretical chemistry as a field. Basically you got started by physics and there were almost no chemists doing it because it sort of started out from atoms and got from very small molecules the bigger ones. Right, so that's what chemistry is. And Debbie Chem is a pure plant. So we have everything in Debbie in. It was started in around 2004 by me. But still for a while I was mostly the only guy doing it. And then there was Li Dao Bing for a while, but he stopped doing chemistry apparently. So he dropped out again. And Daniel Leiter is the other guy, also a German who does a lot of work for Debbie Chem. We have, though, still a couple of people doing specific stuff. So Nicolas Brain is packaging Gromax, which is a pretty popular package. And Filippo Rosconi, I hope I pronounced it right, is doing a lot of the mass spectrometry and then polymer stuff. But he's mostly working on his own with a couple of people on it. So I have to say to me and Daniel are mostly maintaining most of the packages and there are some people doing various stuff. So as we say, we have 20 project members on Alio, but only a handful are really obviously active at all time. We have over 50 packages maintained, team maintained. And yeah, that's roughly it about it. So these are the nice main statistics from Andrea. So there you can see, so Daniel is the red column and I am the blue one. And then you had Li Dao Bing in 2007, quite active and then dropping out. And other people like Andreas, who is somewhat active or others. But as you can see from the development list, this is the Debbie Chem development list. It's mostly me and Daniel, well, posting there. Also, I think all the package uploads get filtered there. So that comes in there as well. And if you look at the commits to the... Oh, that's unfortunately the wrong thing. Wait a second. What was the name? That was a copy and paste error. Right, that's it, sorry. These are the commits to the, I guess, some version repository. I mean, Andreas, do you know whether this is also tracking the Git stuff, but probably not... Well, it's from the mailing list, so what is it? It's also Git, okay. Right, also there you can see that most of the commits have been done by me or Daniel. Getting more or less active. I don't really see the people from who were doing Git there, so I'm not super sure it's actually... Maybe not so many, yeah. Okay, but that's just so you get an idea of who's actually mostly working on this. And yeah, in general, we would certainly like to have more people involved, but you have to say that chemistry as a field is not super popular compared to biochemistry, for example, which a lot of people are doing. There's not a lot of free software. Well, there was not. And it's rather difficult to find motivated people who really are interested in packaging. I mean, if somebody's interested, of course, talk to me. But it has been shown that it's not super easy to get people. So the original mission when around 2000, when I started it, there was ChemTool, which was the thing that Günther Bechler had already uploaded, I think, and I took over shortly afterwards. And I used that actually during my studies when I was studying chemistry in France back then. And there was a couple of other packages like MPQC, Massively Parallel Quantum Chemistry, and Psi3, which is also an up initial program to compute molecules. But that was about it, I would say. I mean, I didn't do a huge analysis on this, but there was not very much chemistry free software back then. Probably I'm missing some. But so the initial mission was package all chemistry related free software project because anyway, there's only three or four. But today, if there's a new paper out in one of the chemistry journals and somebody says, hey, we have a new project, then there is at least a 50% chance that it's open source. So everybody's doing it. It seems like every PhD student is dumping their stuff somewhere. And there's also been a lot of code dumps by groups which decided to open source their projects. So right now you get, well, you always have the problem. There's one PhD student working on it and he's doing this and then the next one comes and he does something else. So what to do with the code? Sometimes they just dump it on the net, sometimes it just gets lost. Or sometimes the whole working group dissolves because the professor is retiring. And then also the code is unmaintained. So you have lots of these troublesome things. This down here is just the current content of, we have one file called Prospective Packages in our subversion where I keep track of free software projects which I find on the net or while looking through journals. And these are not packaged yet. So there's, I don't know, 30 or 40 of them prospectively to be packaged but we just don't really have the time. And also it's not always my field of expertise. So it's very sometimes hard for me to figure out whether one package is really useful to package or not. So the current mission I would rather say is packaged the most appropriate chemistry-related free software projects because now there are so many. So we should pick out the ones which are useful, which are good, which make sense. And we should probably remove also, we should start removing packages which are no longer maintained or which have been superseded basically. There's a new package which has the same functionality but it's better or works better or is nicer. So we should start removing them. For example, Chemtool would probably be a prime example. So there hasn't been updated by the guy Martin Krueger who did upstream mostly since 2008 I guess or so. And now there's various other packages. So Chemtool is one to sketch molecules, organic chemists do that a lot for papers. So you have a molecule and you sketch the carbon chain basically and then you get a nice image of it, like a 2D image. And we have five or six of these packages now in Debian. And probably we should really say, okay, this one is really good because it should be dropped or decommission or whatever. That's something we have to look into. And also we have to figure out what read the target is. So there's also quite a few packages like already mpqc. It's called massively parallel, but of course that was 15 years ago. So it's not really that appropriate anymore. But there's quite a few packages which are projects which target supercomputers. So they work really well from 10,000 cores on, maybe not so great for workstations. So we have to also see what our target is. So my current target is my notebook, but probably it would be better to say, well, we want to target 16 core workstations or really small compute clusters because honestly all the really big clusters run right at the enterprise I guess. I don't know whether anybody knows that Debian, well, chemistry related Debian cluster where people actually use this. So it's difficult to get some feedback from users. So we should probably start looking that small compute clusters and workstations are really nicely supported and then look to support the really big clusters. So to give an overview of what Debian does, the current fields in chemistry that we're actually putting packages on. So maybe one of the interesting stuff is visualization of molecules or also visualization of biomolecules and also the electronic structure. That means the molecule orbitals if you know what I mean. So you run a compute job for a molecule and then what traditionally has been the case is you have to write an input file in a text which says, well, this is the molecule, this is the method I want to use, please compute it. And then you run it on some compute cluster and then you get an output and you have to parse the output for interesting stuff like what's the optimized geometry or how many electrons are there, what's the energy and that kind of stuff and after parsing it you want to visualize it. So because looking at text files is not really nice and there's a couple of nice visualization projects for that and the task is called Debian Cam Visualization. Then we have the structure drawing which I already mentioned with the cam tool and that's mostly this view-added 2D thing. There's a couple of others, BK cam I think is rather nice. And then huge field is cam informatics actually. That's toolkits which look at the structure or the chemical of the molecules and they can for example superimpose one molecule with another or they can do things on some databases and that's actually one of the fields which is also used in industry a lot. So there's a couple of really good cam informatics packages I will get to that later on and they could use or even get open source by big companies. For example you have a protein or something and then you want to see which of my pharmacore targets might actually be useful for this thing so we can have a new pharmaceutical and instead of doing this for all 10,000 molecules in a lab which takes ages to figure out you just run it over the cam informatics toolkit and they give you the molecules which fit best into this also. So there's some huge applications there. And then molecule modeling is another field where usually you use a graphical workstation to come up with molecules that you want to study maybe later on in the lab or generally and you don't really run huge computations on it but you want to know roughly the geometry any kind of things and use that. So we have a couple of packages there in the DebiCam modeling task and then a huge thing is computational chemistry. That's basically these programs which take input, run this input on some quantum chemistry methods and then produce some output. There's actually three of them. Appinicio, semi-empirical, the difference is how much information you put in. So semi-empirical methods mean that for every atom or every element you say, well, this element if it interacts with that element on another atom, there's roughly this energy level to be very precise. Whereas Appinicio basically all you say, well, this is my molecule, it has so and so many electrons, please compute it and then it's totally from first principles. And of course that also takes much longer because everything has to be calculated from the beginning. And MoMAC is a pretty bad name for molecular dynamics. That means you run a simulation on maybe a molecule or maybe a protein or some other big structure and you see how over time the structure changes. Maybe you put some pressure on it or you just want to see how it evolves over time. For example, proteins usually are structured from a solid phase x-ray structure. And if you want to see how it really works in water or some useful liquid, then you can run a molecular dynamics simulation on it and see how that works because the structure is usually different in a crystallized solid state thing which you use for x-ray or in the water environment. And finally we have mass spectrometry as I said. Right now Debbie Campolimia also a pretty bad name which is about, I think, well, Filippo Rosconidus does it, so I'm not an expert there, but I think you either use it to run spectrometry simulations or to also analyze the spectrometry simulations by looking at huge amounts of data, for example, for mass spectrometry. You usually bombard a big molecule with some energy and then you see which fragments are evolving and then you have to model somehow and figure out what the specific molecule was if you don't know what it was before. I'm not super happy with the names of the tasks. We had a discussion with Andreas before the Weezy release. I would like to rename them at least a bit, or maybe we can just not expose the package name so much and make the description more useful for these. Because as I said, MOLMAC is not really that interesting and there's better things. So I'm mostly a computational chemist, so that's what I do mostly. So my field is mostly computation chemistry and I'd also do some cheminformatics, so I'm just showing what kind of projects now there are. So some of them are doubled, but as I said, in the beginning there was mostly mpqc and PSI, both in Virginia Tech but PSI also in Georgia Tech, but nowadays you have quite a few others. You have NWCAM, which is a very generic program and has been open-sourced recently three or four years ago and it's extremely mature. It's from Pacific Northwest National Laboratory, I guess, in the West Coast. And this is basically a really, really general-purpose quantum chemistry application. And then you have local, so to say, CP2K, which is developed mostly at ETH Zurich and University of Zurich, but also by some other people. And this is an app-initio molecular dynamics code, mostly, but it works extremely well for all kinds of things. It's also extremely well written and done. And well, there's a couple of others. So CP2K, for example, was started from scratch as an open-sourced project. Whereas NWCAM and ASUS have been open-sourced later. I think PSI code also has been... PSI has also been open-sourced later and I'm not quite sure about quantum espresso, that used to be PW, SCF. I think also it was open-sourced later. So you also see there the difference in how people approach it. And GROMEX down there is a molecular dynamics code, as I said. That's Nikolas Brain is doing. That has always been an open-sourced project. And MOLDS is a rather new code from Japan, which is also completely new. Whereas, for example, MOPAC7 is unmaintained these days and it's really, really... I think it's still Fortran 60 code, for example. So nobody really wants to touch it anymore. And then we have molecular modeling. So this is, for example, Avogadro. And there you see the orbitals of, I think it's a benzene molecule. I took that from screenshots that were net. And there you see how the... So this was calculated by some quantum chemistry application and then fed into Avogadro, which actually uses open-bubble. It's a cheminformatics toolkit, which also does these kind of things to look at the molecule orbitals and the output and then visualize it. So you can see where the electrons are, where the molecule orbitals are related and also see where the geometry is. But you can also, for example, change the atoms in here. You have this drawing tool and you can do other stuff with the molecule. It's a really nice program. Unfortunately, right now it's getting rewritten because the main developer started to work at Kitware. The people who do also VTK, so they're trying to rewrite it for VTK. And the new version is not yet really stable, so it's not super clear what will happen with that. We'll see. The other one, which is also molecular modeling, is PyMol, which, as you see, is more for biochemistry applications. The other one, Avogadro is maybe more for quantum or computational chemistry applications, but it can also visualize proteins. But PyMol is really, really good for biochemical stuff. So here you see a protein and you see lots of water dissolved into some water molecules, it's the blue ones. It has a rather bad-looking... So the other one, Avogadro has a QT application. It's not very old, it's nicely structured from a gooey point of view. And this one is a very old TCLTK application with OpenGL. The graphic user interface is not so great, but it makes really nice pictures. But you have to say that this is a ray traced. So it has an internal array tracer, so this is not... Well, it takes a while to ray trace this. This is not the actual output. And then, as I said, there's the chemical informatics. There's various good toolkits. OpenBabel is the one that I was also involved in for a while. This was started by a company called OpenEye as the OpenEye toolkit. And they did it under the GPL until they wanted to have a rewrite of it, or they finally decided to take it proprietary. So me and Geoffrey Hutchison, a professor from Pittsburgh, decided to start the OpenBabel project. And the problem is that the license is GPL version 2 only, and that's pretty bad for a library. So for example, that's also one of the reasons that Avogadro is not using OpenBabel that much anymore. Avogadro 2 is BSD licensed, and they don't want to link to OpenBabel and become tainted with GPL. That's a bit of a shame, but otherwise it's a nice thing. Over 40 projects use it. There has been a lot of downloads, quite a few papers, and also other projects interfacing with it and or using it for it as an informatics toolkit. And then there is RDKit, which is, I think, partly at least written by people from Novartis Company, but it's also a very nice and mature toolkit. And CDK, CDK is the other one. This is actually CDK is not maintained by the DebiCam project, but the Java people. But it's also a long-running toolkit which can do lots of interesting things with molecules. And the last one is Indigo, which is rather new, but also mature. And then I just want to show down the two, it's Symphony, which is a meta Python library where you can, which integrates all the four toolkits on top. And for every step, you can always use the most appropriate toolkit and you have a nice Python interface to it. So that's a very nice way to handle all these different toolkits. And if there's a method implemented in all of them or in more of them, then you can choose which one you take, but otherwise it will take the nicest one. And the same with the CAMFP, which is called fingerprint. So fingerprinting is if you have a molecule or you have lots of molecules, then you basically generate a hash of the molecule or a smaller fingerprint with the interesting parts of a molecule. So you can more easily query a database, for example, for it, because otherwise the 3D information or even the otherwise structure information of the molecule is way too big to really have it for hundreds or thousands or millions of, well, rather millions of molecules. So there's various fingerprints being invented by people to do that and CAMFP is also integrating all the fingerprints done in these CAMFP packages above. So you have a distinctive interface to it. So just to show how good these, or how some of these things can be done, this is the one CP2K I told you before from Zurich, ETH Zurich and University of Zurich. So they recently released a paper saying linear scaling, self-consistent field calculations with millions of atoms in the condensed phase. So this is something that hasn't been done with any proprietary code, for example. There's various proprietary ones, but this is state-of-the-art research and they are really able to scale extremely well in a parallel phase. Of course, this doesn't make sense to run on a Debian notebook, but the code runs generally extremely good. And another one is Psy4, which has not been uploaded yet, but probably will be during Debconf. And they were able to calculate on a very high level this DNA complex. And for example, this is a, well, I don't know, some website citing that free software to speed drug development. So there they have some nice publicity as well. And this is also, I mean, this method has been implemented in one other proprietary code, but basically this is also state-of-the-art research. The other thing, which is really nice, I showed you PyMol before, and it's really been used for a lot of journal covers. So you have a journal and then, well, back then when they were still printed, every journal had a nice cover with a nice picture. So usually it would really take a long time to prepare a nice picture. And PyMol has been really on a lot of signs, or the penas or whatever picture. So there's this wiki page with all the covers. So you can see that people are really, really using it for to display their signs when they want to show off how nice whatever they did was. Oops. And the last one is Asus 3, which is a code from University of Florida, and I just want to highlight that. It says the main customer inside Department of Defense started to use the new parallel code in 2007 with the parallel method in Asus 3. Their productivity increased dramatically with the serial Asus 2, that's the one before. They could investigate one transition state per month, so basically one reaction, with Asus 3 running on 128 to 256 processors, they could do one per day. And down here you see how this thing scales, and this is per 10,000 processors. So I think they run it on up to 60,000 cores. So it's also a massively parallel thing. So this is real, useful, or state-of-the-art software that we have. And they are all in Debian, except for PSY4, which PSY3 is in Debian, PSY4 has recently been released as a beta version, and I didn't get around to upload it, but I will probably do that during Debcom, if I hope. And then the other thing that we are doing is having package interdependencies. So a lot of the libraries depend on each other, and can be used from one or the other, mpqc, version 2 or 3, for example, and we have one thing which is important, is the generation of these text files for the computational chemistry packages, because this is very tedious, so it's nice to have a nice graphical user interface which generates it, and you just have to run it on a compute cluster. So for NWCAM and MOPAC7, we can do that already. We want to do it also for others, but, well, we probably have to implement that ourselves. The authors don't seem to be interested in that right now. And the other thing is parsing of the outputs and visualizations. So there's also Avogadro, which mostly does that for a lot of these packages, but GapEdit is another one of the 50s we do. Right, so I just want to come quickly to what we are doing in Demian. So right now we are mostly having all our packages in Subversion or Git, so I'm mostly using Subversion still, and Philip Rosconi is using Git. And we're using, well, 30 QuiltFormat, which is the standard nowadays. What we try to do is have, or at least what I try to do is have as good as possible long descriptions where people can really see what the package does. So include all the main features and also, for example, if it's something which does file-format interconversion or is able to parse outputs, then we want to write down which packages or output formats are useful and be done. Or also the supported DFT Functionals, the density functional theory. There's a lot of different functionals and to do that. And the other thing is the way it's parallelized. So whether it's MPI or OpenMP or a hybrid version. We always, except for Gromax, I guess, we always use the default MPI implementation, MPI default dev, that's very nice. It works quite well. And we're using this upstream metadata that Andreas was talking about before in the way to have a citation or I also try to put in the principle of publications so people can have a look at the journal papers and the upstream registration site is applicable. I think we have two or three of them. And the upstream source code repository if there is one. So we also try to do some quality assurance. We have some peer review, which basically means that Daniel is going through all the packages and fixing whatever he thinks he should fix. So maybe sometimes he finds stuff. So he's very, very focused on detail. So the packages are usually in a pretty good shape. And we always run the upstream test suite if possible if there is one. We, well, we have usually support to bypass the test suite with NoCheck if that takes it so long. And what I also did, at least for Weezy, is to not put so much strain on the auto builder. So we only, we try to pick useful test suites from upstream, which cover most of the functionality we think is useful to our users and not run the whole upstream test suite and take hours on and nips auto builder would take maybe days. So, but what we also try to add now and probably we should have a discussion and the bigger thing is to have as full check that build option, which will then really run the whole test suite if you want to do it locally and check that. And one problem we have with that is some packages are really bad because they just run diff on the reference output and on the generated output. And if there is some numerical noise, then they say, well, this test suite has failed. Some are really good in saying, well, the tolerance is 10 to the minus 12 or 10 to the minus 10. And then they're good at figuring that out. And only if the tolerance is bigger, then it's actually a failed test suite. So we have some trouble there. And we have watch files. Also Daniel is very good at doing that. So we can always see whether there is a new upstream version. He's doing that all over the field because I never looked into it in that detail, but he just knows how it works. And so we can always see whether there is any upstream version. And what I would like to do, but we haven't done so far, is install time test suite so that when people install it on their machine, they can still run a small test suite to see whether the packages installed successfully. We frequently have to change things in upstream because, as I said, a lot of this code has been dumped on the community or was not really engineered from scratch as an open source project. So what we probably use or need a lot is hard-coded data file locations because we put our data files in user share, some essential data that the program needs to run. And this is usually not thought of or either you have to have a configuration file for every user or you just put in where it's also very popular as having environment variables. We want to have the program run without that. So we additionally hard-code the user share, whatever data file location into the program so it always at least finds the data files that we supply. Also frequently we have to fix the build system because it might not even be done for installation or other stuff, desk dear is a lot of things, but I guess that's a regular thing. But with all these scientific work, it's usually not computer scientists but physicists so they are slightly more sloppy with build systems and stuff. Also Daniel is very good at writing man pages so he either fixes up the upstream ones or he even writes man pages from scratch. That's also very helpful. And we help with copyright and license clear up if there's some trouble and it's also not too uncommon. So there's a couple of upstream horror stories I wanted to, well, just put together. We have a lot of things where people, that's also part of the registration stuff that Andreas talked about. So in order for them to really be able to tell their funders that, okay, we have so many users, they require you to register as a user. And then sometimes they just put you on the social download page afterwards so you really have to register with your whole name, email address, institute, and then they say, okay, thanks, now here's the source for download page. Or users have to register at a website. I mean, it can show this one, for example, I don't know whether you can see it. In order to download Berkeley GW, it's not packaged right now, but you also acknowledge that you're expected to site the following papers and you must create a user account on its website. Even after you created the account, even back then when I first downloaded it, they asked you a question like, what does GW mean in Berkeley GW? So only people who really know what they are doing can download this stuff. It's quite difficult. Another story is the Alpar package, which has a good repository, but you have to ask for access. It's not public. This is bad. I cannot really see it. So you have to ask for get access registration and then you get a password and then you have to always use the password for the good interface. Also, just to make things more difficult for everybody. That's the CV public password login. Okay, I want to go to some of the challenges we have, which is Fortran 77 code. So I guess not a lot of people have to deal with that all the time. We have quite a few of that packages and that is not very nice to even change if you want to change something or fix bugs in. Luckily, most of the codes are rather mature and are not getting changed a lot, so we don't have to dive into Fortran 77 or even Fortran 60 code a lot, but it happens. There's also a lot of handmade make files around, which is not very helpful, so they don't use auto tools or CMake or anything. We always have to dive into these handmade make files. They're quite proud of it, but it's not really the best way to address this, and some of these packages have never been intended to be installed at all, so they don't have an install target, for example, because they assume that you run them out of your home directory or wherever, and some of them might only be useful for supercomputers. There's Asus 3 that I showed earlier, which runs on 70,000 cores. It doesn't run on one core, so if you run it on one core, it's like fault. It took me a really long time to fix this before Weezy that you can run it just on one core and not in a parallel fashion, and the authors never thought about this, apparently. So, okay, and just to give you an idea of these upstream things, I've put together a table showing the different things they have, so this is for some of the computational chemistry packages. You see the license, most of them are GPL, that's nice. You see the language, well, some of them are C++, but some of them are Fortran 77 code, and Cp2K is Fortran 95, at least, so it's rather nicely engineered. The project hosting, you can see here, I mean the main point I want to give you with that table is, well, they are open source, but are they open source projects, right? There's this, I think there was this 20 question thing, like, do you have a public bug tracker or something, and if you don't, then you get 10 minus points, and then in the end you can see if you're at less than minus 100, then you are maybe an open source project. So, for example, NW Chem, which has been open sourced like four years ago, it's still only developed at Pacific National Laboratory. It only has a private code repository, so the only thing they ever do is that actually they have a release tarball, and then sometimes they dump development snapshots of the tarballs. They don't even have a bug tracker, they don't have a developer mailing list, they just have a user mailing list, and they don't really have project hosting. Whereas, for example, Gromax is really nice, it has a bug tracker, developer list, user list, and it also seems that all the development is actually on the list and not on some hidden list, and it uses Redmine and uses Git and everything, so that's nice. So, you could say that Gromax is a really nice open source project. CP2K is also rather good, except that it seems like the developers are mostly developing their stuff in a hidden fashion. So, you get everything in there as a version repository, that's not the problem, but there is no real discussion about what features should be done or what methods should be implemented next. That all seems to happen either because everybody is in Zurich, they just meet up every, I don't know, month, or there is some hidden list that I don't know of. But otherwise, it's a rather nice project, and also the Psy project is not super great. It has a bug tracker and that's about it. And then they dump, they have a private repository on GitHub, and they just dump the tarports. But if you look at Cheminformatics Toolkit, it looks actually much better. So, again, most of it is GPL, but it's all C++ or Java, everything has been written from scratch. It's nice. Almost everybody is using Git these days, mostly on GitHub. CDK is using Sourceforge for some reason, and they all have a bug tracker, developer list, user list, and all that kind of stuff. The one thing which is not so great sometimes is there is no stable point releases. So, we cannot really use that to improve maybe also Debian stable at some point. I mean, it's very difficult to figure out which changes are useful and which are not. So, just to come to an end, this is some of the stuff that we want to do, or I want to do is sort our tasks. So, this is not so great right now. As I said, the names are not so great. We should also split up maybe some tests or make some new tests. We should package some more projects. The quantum Monte Carlo ones are also very important, but not packaged yet. Maybe quantum dynamics, but there's not a lot there, unfortunately. And complete autodocking. This is also probably in collaboration with Debian Meet. Autodocking means you have a protein and you try to find with a molecule where it fits on the protein. So, you can have these interactions between the protein and the possible pharmaceutical. Package bundle parallelization libraries. There's a couple of libraries bundled inside these projects. We would like to, if possible, split them out so they can be used for wider application or package some of those matrix computation stuff. One of the things that I'm really interested in is hybrid MPI OpenMP because that's probably what most people would be using on a cluster. So, you have OpenMP for shared memory on one node and then you have MPI if you have more than one node, one more than one computer to use it and then you can parallelize easily over from one to many computers. OpenCL support. There's a lot of computational chemistry things not trying to do CUDA or, well, OpenCL, but I'm not sure whether there's still already a really free implementation. I talked to somebody recently who said that for, I think, Radeon, ATI things there should now be something free, but NVIDIA is doing the CUDA stuff and Intel is also doing something. So that's most of the proprietary, unfortunately. There are some things, as Atlas is doing, so we would like to be, the user, be able to recompile the package with a depth build options custom thing and then it gets this auto-tuned and better thing for the user so the package is optimized for the particular system that the user has. More correctness testing is always nice then we have this problem with the Fortran 90 module files which I just tried to discuss on a Demian Science mailing list because the Fortran 90 projects need header files but unfortunately those are binary or one are really compiled with binary so that's rather troublesome to figure out and also Gefortran seems to change the API every time it releases so there is some trouble there. Maybe multiple compiler support. It's not so bad. Well, that's basically it. The other stuff, we would always try to suppose it right. Okay, is there no time for questions now? Well, there is a DebiCam buff right as the next, I guess, in the buff room so if somebody is interested in it we can meet there and discuss and or if there are questions. Okay then, thanks.