 Debian signs around table. So as in gender, I put forth, I didn't get so much input from other people, but I put up some stuff which came up in the other talks like data packages. What I also think we might talk about is exposing the task packages on Debian.org more, as you mentioned in your talk. I'm trying, yeah, how's that going? Edit. Preferent? No, it's not preferences, right? Ah, yeah. Is that better? Ah, this way around, now get it, yeah. What? Ah, thanks for the technical support, perfect. So, yeah, I put up refocused tasks, merge on packaging best practices and then some stuff. So, one thing which came up is that the task packages are really great for once. I mean, that's certainly true, but if you look, for example, at the, I think it was like the imaging task which has like 70 packages. And for example, other tasks have loads of tech packages and one thing we could think about is maybe how to make it easier for people to install it. So, on the one hand, have the task packages which are a super great overview of what you can have in Debian, but if they say, okay, I wanna do, I wanna do scientific publishing and then I'm not sure it makes sense to bomb them with 100 packages with every tech-related package basically we have or like 17 different ways of making diagrams and plotting. It's difficult. So, I don't really have a good answer, but I feel that converging on a couple of really good ones and how do we figure that out once would be good. So, if somebody has some ideas on that. Or is there, is everybody happy yet? You can take, sure, take the microphone. So, maybe that will be, oh, yeah, right. You can also sit here, I don't know, might block a bit the- I'll just sit here. So, task files, they provide us with pretty much highest level after the blend of what we are dealing with, right? So, they're really coarse and they're not orthogonal, as I mentioned, that we have packages present in multiple of them which creates a hassle how to maintain them in all those tasks across different even blends. So, that's, it's solution which works so far but it's not the ideal solution. To mean by a blend, let's say they've been science and they've been met. That's two different blends and they have separate tasks files. So, this is blends, so what blends? So, it used to be custom Debian distribution but that was very confusing because it's really Debian. So, now we call it blends. It's basically a set of packages in Debian which belongs to something. So, how is that different than a task? Well, each blend has multiple tasks. There is a page which leads, let's say in science, it's not just science, right? It has different fields of science. And actually Debian met could be considered also a field of science. That's why there is this great deal of overlap. But what this, we are liking seems to be is ontology of all those packages and finer kind of characterization of the packages in terms of what field they belong to and what they work with. We have tags, right? They signal some information about what formats it works with but the list is restricted. It's not easy to expand it. But, let's say the easiest start could be to provide tags for every blend and task, right? So, for every package, we just put it in a respective, we tag it with the respective blends and tasks as the next level and maybe sub-level. Let's say in imaging, as you pointed out, there is too many packages. And some packages work with, let's say, just anatomical images, anatomical scans. Some packages, they work with functional data, do functional analysis, and that could be tagged as the next sub-level of that. We just don't have that infrastructure at the point. That's Andreas Tillow, by the way. Andreas. Who does these tasks? Andreas, are you suggesting that we just used ebtags, or I'm not sure what you're trying to get at. Andreas says ebtags, question mark, question mark, question mark. That's difficult. So, I'm trying to elicit some. It's late at night there, I know. I'm curious how, I don't, I don't, I mean, I'm just being. Just one second. So, the difference between blends and tasks is clear. So, for example, that's Debian blend, and it has like 20 tasks for different things, right? So, it's medicine, but then you have medical data, dental, epidemiology. And by the way, it has a typesetting task as well. And I'm probably imaging tasks, yeah. Yeah, I think we've got some duplicate packages in Debian Science and Debian Med here. Okay, so please go on. I'm not sure I even wanna ask, because I'm just not sure I actually understand the utility of this at all, but maybe I shouldn't go down that route. The purpose is that we have more than five packages in Debian, and if you want to know what packages are there for you, for a specific purpose, you can look at DapTex, and then you can find packages that work with images, but for many, if you go deeper into specialization, you quickly end up having either thousands of packages or none, depending on what you looked for. And the task files are the source of, looking at what packages listed in what task file, and the task belongs to some, represents something specific to what you can do with it. I think I understand, but I usually sort of know what I want to do, and maybe want, or would like a list of things that do the things that I'm interested in. But I would never, I actually don't like tasks at all, because I never wanna install everything that does one thing. And it's hard for me to imagine that anybody really wants that. Right, but in addition, the task files are used to generate the meta packages, but they are just one effect of the task files. For us, for a neurodiving website, they are the primary source of meta information, and we don't look at the meta packages, we just fetch the stuff from SVN, and we have the most up-to-date thing, right? Yeah, but then my response would be the same question, why not DapTex? You just tag packages based on whatever their utility is. Because if you can, we can, right now we can tag all our packages with, what is it, tag needed or something? Because, and there's lots of discussion about, okay, when is the threshold reach to add another tag, right? And there's consensus that we shouldn't have a tag for anything really, really specific. But that's pretty much precisely what we want for science, because it is really, really specific. So we have with the task files now a solution that we know doesn't scale, right? One of the task files has 70 packages, so the solution could be, we split the task, right? Now the package comes, and now it doesn't fit only in one task, it fits in two. So we need to duplicate that over and over. And the solution would be a tagging-like thing. But the way that DapTex is, you know, what it's trying to achieve now, at least in my perception, is not doing the job. Although technically, it's pretty much ideal. Well, why can't we just make it do the job that we want? I mean, it's just tagging, right? You could have an infinite number of tags on a package. No, that's the point. Somebody maintains them. You can ask for an infinite number of packages, but they won't happen automatically. It's not wiki-like. You can tag any package with any tag that there is, but you cannot. You can't easily generate new tags. You can suggest. Why is that? Does anybody know why that is? Well, there was a comment on IC. For example, they do not create new DapTex if there are not more than some number, seven, I think, of packages in the archive. So you want to have, like, okay, it doesn't make sense to have tags for something which is only two packages, so not to have too much tags and stuff like that. But sometimes there is just two things in the world. What's wrong with having a package? Only one package with a tag that is only on one package? I'm not sure. I mean, I think one other point is that through these tasks, as they are in subversion, we also use some more metadata on it. For example, right now, I don't believe all these references and biography, they are actually maintained in the task subversion. And so it's not just a list of packages, but also some related metadata. And probably I think it's a good idea to move that metadata into the package if possible. On the other hand, you really have to acknowledge that doing it this way really makes things easier. So, I mean, it was really awesome what people showed on these task packages. You have all that kind of stuff, like bibliography, references, and so on. So you can easily create new stuff, like Andreas is doing, and make it great. But then we should think about once it has settled to move the metadata back into the package or the packages list file. Moreover, those tasks files are crucial, I think, for visibility of packages which are on the way to Debian. So whoever, let's say, wants to package and there is ITP backfiled, it's listed there also if it was added to task files, already with the reference, already with tentative location of the perspective packages, right? So all the information is there, like it is already in the Debian, which is quite important, as Michael pointed out, why it's not there yet, and maybe why it cannot get there at all. So it's more than just kind of duplication of information, but it's indeed easy way to add information about upcoming packages. Adam, I was okay. Thanks. Note on dead tags, I think the reason that for restricting them and for requiring that a large number of packages to use them is they're basically an aid for searching and searching large numbers of packages. And so if you create large numbers of tags, then you just recreate the same problem. So the idea is to try and capture user interests in as few as possible tags and capture as many packages in as many ways as possible. I apologize if there's some gap in my knowledge, but so how do actually dead tags come into packages? So initially there was a campaign where they wanted us to go to the website and do it. I started doing it for some packages and then it became, and the web interface was suboptimal because I had to really do it manually. If it were, for example, something like I can add it to a control file below my binary packages, then I would be more encouraged to do it. But so I stopped and maybe someone else tagged my package or some, I don't know, something happened. One, so if the dead tags is going to be something which you don't control and someone else can add tags or can disagree with tags, as long as that is what is going to happen, you can't depend on it to group your packages the way you want to, right? Shouldn't you as the maintainer or group of maintenance control the tags and then achieve it? Through the control file these days, you can add tags, but you cannot add new tags, can you do that? I don't know, I'm not pretty sure about it. I don't think so. You cannot, okay then, sorry. I'm not really a high user of dead tags after that. Yeah, I mean, that's one thing. Dead tags has been, it's important, but I really... It's still not something which is codified in one of those, you are pointing to those many documents, developer reference, whatever. So it's still not there, which as you make it there, it might creep into more packages and become more useful, right? Is someone here using the tags? Okay. There is your answer. Well, at some point I tried to win. Yeah, me too, I tried. Through all the packages, but since it's detached from the actual packaging and maintenance process, it's... Yeah, I don't see the problem. I tried to forget. I like blends because you can see the result immediately, but with tags, you can't... Where are we? Right. Thanks. Hit somewhere, Evan. Moreover, tagging if it was done in control... In control file. The control file is natively providing you a hierarchy. First, you specialize source, right? You give the tags for what is the domain of the task, but then you give for dev, you give library, development, right? So you can specialize right there, and it's native. With, I believe, dev tagging cloud, it's... You need to go binary by binary. Yeah, binary by binary. So it just doesn't scale. It's painful. Okay. So maybe we should see... David, please, check it out, Mark. Oh, I don't think it's just us. I mean, I think that it sounds like dev tags has issues that should be discussed and conceivably fixed, but maybe in a larger context. Yeah, maybe it's difficult. So maybe we should try and have a dev tag... Is there anybody at DevCon who is a big dev tags advocate? Right, Enrico is not here, so I'm not sure. Yeah, you can see it here. So Andrea says we should go to the task pages, and there you can go... There is a page, there's a button on the task pages, which, well, it blends pages, which says go dev tagging, and then you can modify the tags. So basically, through the task page, there is a low barrier of entry of doing that, just as an informational point if you want to know how to do it. But yeah, I don't think there is a big dev tags person around. So, I mean, I would like to move a bit on. It's already half, 20 minutes. I mean, something I would really like to discuss, and I'm not sure, I mean, if nobody really likes it, then we can just drop it. So we have the social contract, which says that it will always be free and stuff, but why don't we have a contract to academic upstream people saying, we will make sure that it is very easy for people to register on your site or something like that, because what the task packages right now do is you just go there and you click and you can register. I mean, that's really helpful for a lot of upstream academic people because that way they can show their funding agencies that actually their software is getting used and they get a lot of money out of it. So a lot of times, I've seen in the last couple of weeks, I've seen that several like programs or codes in my field, they were behind the registration form, right? So you had to put in your name, your address, email, affiliation, and you said submit and then you would get an email with a password and then you can FTP download and then actually it's GPL. So I'm not sure whether they know that I could just redistribute it if they put it under the GPL, but I think it's this whole mindset of having to register is basically because they are afraid as soon as they put it on the internet, they don't have, well, they don't have control, but also they will not really know how many people use it. So if we have something like we will ensure that users see this thing to register or we ensure that people see in the copyright or wherever we make it up, the citation to be used and things like that. Maybe that would as a, not just as a feature, but as a commitment, that would make it much easier for upstream people to adopt it. I mean, I haven't really thought it through what we could put in there, but it might be a good selling point for upstream people to re-license their stuff on their GFSG free license and getting it stuff into Debbie and if they see the academic value out of it, not just the free software value out of it. I'm not sure what people are thinking about that. Let's start with Adam and then you see you next. It's a very good point and the first thought that comes to my mind is to use DebConf though, and I know people complain about DebConf abuse and lots and lots of DebConf things, but it seems like a logical thing when someone installs a package that that would be when they would register. I see a problem with a single machine used by multiple users, but with the same account, stuff like that. For example, say you're teaching a class or something and they're using a software. Like, do you want to make all the students sign some agreement like saying that, okay, they'll do this? It just becomes impractical at some point. I don't know. Well, maybe you could have... Can I just say that I'm totally opposed to that idea. It's totally non-free, right? You should always... No, no, no. I'm not talking about why should it be non-free. I'm not talking about click-through licences or anything. I know, but I hate that stuff. Well, Condor has their own licensing issues, but they make you go through something like that where you have to put in your name and register in order to get access to the source code. Yeah, we're talking about... And I would hate... I would never want to make the users or something. Okay, we're talking about something voluntary here, not something that you have to do, and if it were acquired, it would be non-free. My point is that... They are doing it because that's the only way they can guarantee that they get this data or whatever. And I would say that if we say that in the copyright file or through whatever we decide, we make the user aware that they should register for the sake of the profit of that project. So then they can think, okay, is that enough for me to have it as a free license or not? It doesn't mean that we would enforce this in any way on our users. I guess I'm just dubious of that need, really. I think that a lot of people in academia think they need stuff that they don't need. I don't know why Condor insists on making you go through, jump through these hoops to get their source code, but I can't imagine it's a really legitimate reason, really. So, James, I understand your perspective, but you're not applying for a lot of grants, are you? That's true. So I think we have to recognize that it's a painful part of academic life to get money to support students. I just wanted to interject. I wonder if we can leverage Popcon. I mean, it's a... Yeah, I was thinking that. Yeah. It would be at least the first step, right? We can say... Yeah, but that's also voluntary. Yeah, I agree. But it's leveraging existing infrastructure, right? Yeah. So if you go to one of those projects where they want you to register, that's also voluntary. Nobody checks these things. You can put in, I don't like you, and I come from nowhere and just click download and you'll get it, right? It's voluntary. It's just a hassle. The problem is that what we should aim for is the best upstream relationship that we should have, right? It's very easy for us to just register once and say hello, rabbit, and get the software, then put it to Debian. And let's assume that Debian is the thing that everybody uses. We pretty much take away any popularity statistics that they can do, right? So that's a good start for a packaging project, right? They will love you because you don't play the game the way they want you to do. Of course, the license permits you to do so, but what do you gain, right? They are the guys that develop the stuff. They are the only ones, presumably, right? Now you take them away. They're monetary resources. What will happen? It will die. And then you can flag it upstream that and remove it from Debian. Boom. No, but see, that's the sort of thing that... I mean, I agree with you, David, that I'm not applying for funding and that there are funding agencies that make these absurd sort of restrictions, but they're absurd restrictions. And I'm not saying we should go around to all of the upstream maintainers and say, you know, you need to get rid of this stuff because it's absurd. But, you know, most of... Other than in software, there's not doing some sort of like survey of how popular your science is, right? It's a citation index. I mean, it is. It's what determines my salary, basically. I mean... How many people... Sight my papers, yeah. But that's... I don't think that is the same thing, is how many people have installed the package. So square. No, it's... But it's a... It's a related thing, right? It's a related thing. It's not related to the number of people that have installed a package. And so I also think we could just say that we expose the citation details to our users, not as we... that we force it on them, but we say, okay, if the user installs this package, they know exactly where the proper citation is, and things like that. So that might make it more popular for upstream people to work with Debian, because they know if somebody installs their stuff, they... Okay, first of all, let's say they get through popcorn, pretty good... Well, they don't get exactly where, what the people are and stuff, but okay, that's debatable. You don't need that. And then they also... The users know how to cite it properly without having to wait through readme's or upstream stuff. And so if we put everything on that, on a... In a central location, but it's easy to find... Maybe I'm saying the same thing as you are. I think... They just crashed. It's... Sorry. I think it's important that we provide facilities for academics to get their grain in us, but between popcorn and this bibliography thing we were talking about, maybe that's good enough, or maybe there's some other third thing we can do, but I'd agree with... What's your name? Jamie. Jamie, that adding another voluntary thing that only 14% of the people are gonna use it also seems pointless, as well as pointless. How many grants can you get from such vacuous statistics? But if we can give them something real, so is there anything besides popcorn and bibliography support that we can do for packages is to support academics and their grants and so on? Is it really relevant? I am not sure you have to do such things to get grants. I'm applying daily on grants and I don't need that. I agree with you, Graham. So it's true, although I champion that notion that I personally... I personally don't get credit for writing software. I get credit for writing papers using the software that I write, so I think I'm not the right person to answer that. Well, can I say, for example, Condor, you cited Condor, right? They are GPL in principle, but to get the source you have to register. No, they are GPL since a couple of years or something, even if they're not... Artistic, artistic license. Yeah, well, but anyway, what I wanted to say is that what you can do if you increase the visibility of the software, like something like Neurodebian is doing, this is on top of the popcorn statistics, and so they at some point would be, for them, useful to be able to say, well, we are supported by Debian. But at the moment, it's just not a selling point. You cannot tell it to anyone, but as soon as then it becomes an honor to be there, then you could use this argument in a grant. But it's not true that the scientists are not getting credit for the software, because it depends. I mean, if you are writing software, as a side effect of your research is one thing, but there are projects that work, I mean, they are software-based. I mean, they get grants to write software, like Condor is one example. And SyLib is another example. I agree with you. So I don't want to be misconstrued as saying other people aren't in that situation. It's just that because of my situation, I'm not the right person to say, yes, I need this data for grant applications, because I don't. I think it's much less of an initial grant application. If you get funded with a couple of million to produce something, then you have to, at the end, somehow justify what did you do with money. And part of it is to say that it's actually useful, as in it's actually used. But I don't think it's Devin's responsibility to feed them with data, right? But we should make the impression that we are able to play the game properly. So we should make it easy for people that use the stuff to reference it. And if they want to provide that information, maybe to register on their mailing list, and upstream has all kinds of ideas what they want to do with the data, then they should find that information, because they won't necessarily see upstream's homepage. That's what we are taking away by distributing the stuff ourselves. And if we just need to be a nice player in that scientific game, and we don't have to enforce data collection of any sort. How about what can we tell them your software is now distributed on what, 14 architectures, here's packages.devin.org slash package name, and look up the Google page rank for it, and the plus popcorn, plus bibliography references. Now you're starting to make advocacy case. So I think we'd be better off saying we promise to make sure the user sees the URL of your homepage than any of those factors that you mentioned. And if we can somehow even make sure we have links, I mean we do, right? We have all these things. And if the issue is the users don't see the homepage, then we should think about, I don't know, do we want to somehow make an effort that the users can see the homepage? You could just encourage the upstream to have like a banner when you start the software. That would be that splash screen. Yeah, something like that. But let me just say that I think that the thing that I was responding to sort of viscerally is the, you know, I'm a big advocate, I'm a big free software person, and I don't like it when in the academic world people make up weird licenses and weird restrictions for getting their code because of some weird notions they have about needing to get credit for it or needing it because their funding agencies are weird and think that they need this information. And I guess my opinion is that as scientists who are working in Debian and care about free software, we should try to encourage the upstream people as best we can without antagonizing them that using things like GPL and properly licensing their code with free licenses is better for them in the long run than putting in weird restrictive stuff that doesn't, that probably they don't even realize is not going to be used. So nobody, I think, is suggesting that we encourage the use of non-DFS blah, blah, blah G licenses. But the issue is there are things that upstream would like which are not required by the license and we're saying, should we support those things? In fact, it sounds like we have the same goal that basically what we're trying to do is to say if you use these free licenses, we will help you in this way. So encourage people to use the free license. On the side topic, although that's kind of actually a major topic, do we have any flow back to upstream to just give them kudos? We have report back kudos which goes, I believe, to package maintainer, right? We have good infrastructure to propagate the bugs, right? We know how to mark them forwarded. We don't have any infrastructure to... But there's no standard way of doing that? Oh, well, there is no, there are no Linux at some point. But so maybe it's worth thinking about more global kind of maybe approach. How do we report back to upstream about the success of their software? Just maybe gratitude, right? This is what it is pretty much. Popcon is just plain statistics which somewhat works, but not quite so even in respect to those. But there are many satisfied people and they install system, they might like it. There is nothing which hints them that they could somehow besides emailing, figuring out whom to email and saying thank you. And we were getting actually emails from users who were just saying thank you. But it's a non-trivial job for them. And maybe there could be global, not just for scientific software. On your software, I don't know if you develop software, but do you usually receive good comments? Because on Sylab it's pretty unusual that people are sending us good comments or bad comments or comments anyway. And I don't think in Debian we have enough time to do such things. I'd like, but at what point you are sending kudos to upstream and how? And if you know who upstream is and how you can get in touch with him, which is not always the case. And theoretically we have copyright file? Yeah, but you know that in the scientific world some of the packages I maintain are 20-year-olds. So the guy might be dead and I don't have the email. That's the problem, right? We don't know even how to say kudos, right? So maybe it's worth... No, we have no idea how to send them. Maybe it's worth putting instructions into, not instructions, in copyright file. What is the contact address, all right? There are you... Actually we are doing the copyright order, not exactly the author. And what's mean author in free software? Sometimes it's a corporation, sometimes it's a mailing list, sometimes it's nothing. There is the maintainer field in the file head. I'm always talking about machine-readable copyright. Yeah, but you're talking about the then maintainer? No, the upstream maintainer. Yeah, usually the copyright order that we put inside. Well, I think that's a side issue or is there really... I mean, it's a nice idea if somebody does it, but... Well, but that actually puts you into a framework how to create at least some flow from the user's willingly to provide. So let's say if you provide field for mandatory registration kind of thing, right? It's not mandatory, but at least maybe you could collect, let's say, I'm using Debian system. I love it. I have 20 packages which upstream begs for information, right? And I run some utility which just checks which packages actually ask for such information and it just sends them email that, oh, I'm Joe, I love Debian. I run your software these on these. Thank you. Can I move to a different topic we've listed? My question is, you've written supporting non-free compilers like ICC, IFC. I think that's very specific. I think... Yeah, maybe I'd make it more general. No, no, let me tell you. I've been in a university in two countries now for seven, eight years now. You do know which the distribution of choice for them for Linux is? It's CentOS. The simple reason that most proprietary software which proprietary software vendors give is usually only for Red Hat and Red Hat Enterprise Linux. So everyone wants CentOS. So I have lots of friends who use Debian a lot, but because they don't want to muck around with the scripts and change things, the proprietary software is what makes them install CentOS, which is one thing. So I wonder what we can do to... I mean, of course, we don't want to encourage proprietary users or something, but if you want to increase your user base in general, is it what should we do to facilitate people who want to use proprietary software to use Debian? What can... How can we drive Debian there in... What can we do for that? I think that's what the LSB, the Linux standard base, is partly for. Except I don't think much proprietary software uses... Yeah, no, even if it is, lots of proprietary software do work on Debian, but the vendors will never ever say anything other than Red Hat. And the only thing which is equal to Red Hat in every way, except for the trademark things, is CentOS. So system administrators who don't know much, they don't want to say, no, Debian might not work. Only Red Hat works while you CentOS. So that's what they say. Okay, I guess I should say that was the goal of the LSB. And Debian had some input and different things, but so that most software that runs on Red Hat should also run on Debian, if it has. And Alien is a part of that. But I don't know if that helps. Or are there other things that you can think of that we can do in Debian? I don't know. I mean, how can we encourage people to do it is what my question is. Encourage how? Or what? No, I mean, the first thing, if you ask any system administrator, what is your choice? You want to run, for example, in electronics, there's a software called Cadence. I need Cadence. The people who write Cadence say, run it on Red Hat, so I will use only Red Hat or CentOS. Okay, but I mean... That's stupid. Is it an awareness... Yeah, it might be an awareness gap. So most system administrators are not like you and me. So they have been trained in certain ways, and they don't think out of the box, and they're not like the skilled system administrators which we think we are. The proprietary sort of vendor says this, I will use this, I will not try anything else. And therefore, students like me are forced to use CentOS, even though I could try to talk the administrator into trying something else. It's a decision they take. It's a decision they take. But maybe, I mean, maybe I think we should tell the proprietary software vendors... I just think it's a different question to why so many users are using Ubuntu and not Debian. I mean, something, sure, we make Debian better or make it more universal. Now you're right. Since Ubuntu has come, since they say it works on Ubuntu, yes, that's true. But maybe I was just saying, we should get Debian's name listed on these proprietary software vendors supported lists. I mean, I can actively... I can also try to contact the vendors of software whom... I think the first step would be to actually make a run on Debian. I'm sorry? The first step would be to make sure that it runs on Debian. Yeah. And then you can list it. It does, yeah. If it does, I should... I mean, maybe users should tell them. Okay, well, you may... Did you want to go there? Maybe just a short comment that, I mean, outside of universities, there's absolutely nothing you can do if it's not on the box. I mean, no manager is going to sign off on CentOS. I agree. And so... It is only because I have some hope that I'm trying to... Okay, just to be clear. If you're using commercial software that requires Red Hat, then you have to use Red Hat. For everyone else, it's just advocacy. Maybe they've gotten into the habit of CentOS or not, but you can advocate and that's good, but what can we do, not much, other than advocacy? Well, I want the proper... I mean, maybe we should market Debian, the name Debian, to the proprietary software vendors as well. Yeah, but you can do that. It works. I mean, I should do that. Yeah, you should do that. Yeah, advocacy. It doesn't need any technical changes, right? Yes. I wanted to... Sylvester's Atlas question, I was hoping we'd have a moment for it. Right. But I wanted to make a comment. I think this Kudo's idea is awesome. I want to talk about that more, but let moderator decide where should we go? No, I think we should go to that easy recompilation of things. So what we had in Debian for a while is module assistance. I'm not sure whether it's still used. DKMS is used these days to recompile kernel modules. And I think some kind of like that infrastructure wouldn't be so bad for scientific software. Because I have the feeling that at least quite a lot of admins recompile quite a lot of the stuff, even though it might be in Debian, because they think it's just better if they do it like a gentle way, you know, like it's more optimized. So maybe... And of course, it's easy to just apt-get source, apt-get build depth, the package build package and stuff like that and then put it in a repository. But actually having it... So the nice thing about module assistance is that it makes sure that everything... It's manual driven and it makes sure that everything is easily done so you can install it. And it's not really much of a problem and no furniture entry. So Adam first and then Luca. I agree in there. And we've talked about Atlas as an example. Another one is FFTW that can achieve a lot of optimization by tuning for cache and memory sizes and number of cores, et cetera. The compilation time is definitely an issue and if there's some way to background it, the way that, for example, some post-ins tasks are backgrounded, or that some of the old tech packages did that, but the difficulty then is that when the package is installed, you want to be able to run it. So maybe for that, you could have the ref laws in there and then have LD config switch to Atlas so do you think it should be... Well, if you recompile it on post-ins, that basically gets it out of the package management system or... My idea would be to recompile to a new binary package which would then it automatically install. If you're spoiled, I won't know. Well, yeah, we're spoiled. Well, okay, sorry, Luca first. Yeah, so we have to get source-compile that's as simple as that. So I'm not sure we need more infrastructure than that to recompile packages. So the problem with that is that you then have to manage the source and the installing of the package. No, apparently does it install it, Luca? What about just an apt-get-install-compile package name? Well, my point... It's managed in the background. One important point about the modular system in DKMS is that you get a list of the supported to be recompiled, well, drivers in this case, but so it would be nice in that way that admins see a list of these packages support and to be figured out in a way being recompiled easily and then just click on them and then they get recompiled. So they don't have to figure out what they actually want to recompile, but... The way to do that seems to me to have that as inside of apt, right? So that it's... Yeah, but then you have 1,000 packages. You don't want to recompile VI, for example. No, no, no, you don't want to... But just saying, if you want to recompile a package, just give it an install option that does it and puts the .dev, it downloads the source into a very well-specified place. It compiles it there, generates a dev, installs that into app the way that devs usually are, and then installs it into your system. Sounds difficult. Oh, why? You have to get a built environment, everything like that. Well, you have to do that anyway, though. But if the packageer is doing this and saying, okay, I know how to compile this, I'm going to set up the package such that it can be easily compiled on your system, and then it just does it in a known location, that's way easier for the user than to have to manage the source code themselves. Yeah, I don't think we want them to manage the source code. Right, and that's the problem with the AppGitSource is that you do have to manage it yourself. Some people on ISE say that APT-Build might do it. Yeah, but they also say it's orphaned and not maintained. Yeah, Jerome. Yeah, I just wanted to mention, at some point, I put together a package called depconf-src, which is on my website, and the principle would, the source package would be configured. There would be an equivalent to DPKG build package, which would have depconf templates, both from the system for configuring standard variables like CC or depbuildups or so on. And you could include also templates in the source package itself and shell snippets for the configuration script. And the idea was complex packages like you would like to build a cross-compiler or something. You could configure the source package easily. And I kind of like the idea that Jamie had to integrate this into APT at some point. But integrating into APT takes time. Yeah. It's not very easy. But that's an interesting. Yeah, but that would have made my next step. So I just want to mention, if someone wants to work on this, so they should contact me. I remember that Humia used to do that also for licensing issues. But the problem with that class, it is the main problem and what is bothering me. What I like with Devian is when you start a package, it takes two seconds to download it and one second to install it. With that class, I would have to wait 30 minutes to one hour and a half. And I found that very boring on the side. I know that I don't have any other choice, but I found that very, very boring. But it's... I like the idea to install, I think Adam said that before, but I like the idea to install LaPack and Blast and using them while you are compiling the software behind and get the kind of feedback when it's compiled and installed on your computer. But I think it is going to be pretty hard to implement. Well, yeah, you can use the base LaPack until the compilation is finished. Yeah, as for the discussion about app to build and the like, there is also an app SRC package script that supports the options to build and then install the Dev package if desired. So you can't actually do that just with one command. And as far as I know, it's still maintained. Okay, well, oh, yeah. This is kind of tangential to the same point, but related to the Atlas package. Like the problem that you had was, like the machine that you compile might not be the same as the machine that the user might compile, right? I mean, I don't know, maybe I'm too naive, but one idea I have is say you come, like whenever Atlas compiles, it probably generates something like a specification.txt file, like which says, okay, what kind of like threads it decides to use and stuff like that. Yeah, it does. So maybe like when you are trying, when the user tries to install, so you compile the package and you have a specification.txt file in your machine and you supply that. And when the user tries to install it, and you try to generate the same specification.txt file using like a post-RM script or something, and see if those two match, otherwise you compile it then. Or give the user... We got, if you have a look on the number of computer on the market, the probability that the match is very low. Yeah, then you just give a warning to the user, like a menu screen. I think in 95% of the cases, you will have this warning, so I'm not sure it is worth the trouble. Sure, but at least the system administrator will know that he is running a sub-bottom optimal package. Actively. Yeah, does Atlas notify that... I don't even sure. I guess it would be in a news file or something like that, what you're running has been compiled very sub-optimally for your system. In fact, for now you've got something like six or seven already optimized packages. So if you are using base, you know that it will be under optimized and you can guess with the name of the packages that the one you are installing is not good or good regarding to your computer. But for now what I try to do when I was... When I add up this package was to match a previous behavior and it is why I realized that it was crappy. But yeah, I haven't used the Debian news to say that the package is not usable and sub-optimal, but maybe I should do that. I wouldn't have been aware of that otherwise. I had a thought, but I think you just convinced me it's no good. So I'll say it anyway. Maybe it works for things other than Atlas. I mean, there are build farms that are more or less publicly accessible. If it was a question of, okay, look, there's a hundred different configurations which is a small-ish number. But we don't know which ones people are going to use. And so if people could choose, I want configuration 17 and we look and we say, oh, great. It's cached, zip, it's installed. And at least the next person who does that doesn't have to suffer through that. What is your number? 17, right? Just to put the idea, maybe it should be a crumb job. So there is a pool of packages which need to be built and installed and you don't want the user to mess with them. So whenever you install it, it will tell it that it will be somewhere in the ground. Probably do you want it now or later and just forget about it and then it just gets. Would you like your computer to run without any warning and building a stuff which can take a few hours on your computer by night? If you are using, for example, a cluster for HPC computing, you don't want your computer to rebuild the package at midnight and while you are doing a huge computation. Well, for those, you build it once, pretty much. Per each architecture within your cluster, I will, of course, I don't want to run it on all the nodes and waste half days for them just to build. I just pre-build it once and deploy it across the cluster. Yeah, you could do that, especially since usually in cluster, you've got the same computer everywhere. But yeah, the problem with the crumb, you have to know that it will be built that way, which is not very obvious. And I have no way to tell to the user, to the normal user that it is going to be built this way. What I'm worried about is how the user will understand that this package is going to be built. If user understands that he needs Atlas, that's already kind of next level. Well, I don't know. I mean, Atlas is the runtime dependency for a lot of stuff. It's not necessarily that you think, oh, I need Atlas. Oh, I want to do that kind of calculation. Yeah, but then Atlas. What I would like is every user to run Atlas and get the best performance he can. I would like to improve the usage of Atlas in Debian regard. Yeah, but they might blast. I'm just saying, they might just think that the application sucks because it's so slow, they might not realize that it's the problem is that Atlas is generic. They would see that. Yeah, they would see that. Well, so I think we're running out of time. I mean, we can still stick around, but I think the video team should be relieved. So one thing, let's just say one closing thing. So one thing I was thinking about, but I'm not sure whether there's any support for that is the other thing. I believe that, well, I'm not quite sure because I can ask Andreas. Are there any non-free packages in the task files? Yes. Why is the network done? When I would say the non-free. Okay, so one thing I thought about is that well, I don't like non-free, but there's a couple of software codes where the authors basically said, it's basically like a BSD or GPL license, but it's only free for academic use. Yeah, that's definitely non-free, but so my idea was to say, okay, if we do have some non-free software in the task files, then at least it should be free for academic use. So in a sense that if people are using anything from the task for academic use, they can use it. And okay, there should be certainly some disclaimers to that, but I'm not sure whether it makes a lot of sense to a lot of people, but it's some of that stuff is quite... That's the kind of stuff that I was saying when you did it. Get rid of. Well, there is certainly, I mean, I was just talking that there are people are using proprietary software, right? And that is proprietary software. And I mean, as a sense that you have to... There's two things, right? So that we are packaging free software and then we are supporting our users. And they might... The only thing they might... The only possible way they can do that might be through currently only free for academic use program. So can you take the mic, please? There's one here. Really enough. Okay, we can do that. Okay, like two more minutes or so and then we'll just... It seems to me if you're gonna... I mean, if the upstream is nice enough such that you can get the code and put it into Debian, why they should maybe be somewhat receptable to pushing back on the kind of licensing stuff. Well, sure. I mean, we were all free software aqua because we would try that. But I mean, the copyright could be from a university which who don't... But how is that even... How is that even possibly enforceable? How is that licensed? Is that something we can actually distribute in Debian? Yeah, sure. It's not free. We can distribute it not free. But how is that enforced then? Look, non-free means Debian can distribute it freely but it might not mean that everybody can use it free. Yeah, but that's a particularly restrictive version of non-free. Because you can't even say... I mean, who's to say what's an academic environment? I mean, how... I don't know. That seems tough. Okay, that's a good question, but that's a bit besides the point. That's a question for the lawyers. Right. So my point is that if you think you're an academic user, then this stuff is free software except it's only free for academic use. As well, to be discussed. I mean, it's certainly better than non-free itself, which is basically can be as proprietary as you want, no source code, no modifications possible, nothing at all, and also non-for academic use on those, right? So it's just that there is non-free... I mean, I don't think you can... You can't package MATLAB and distribute it in non-free. No, because you cannot distribute it. You have to read... So that's what I'm saying. I'm not sure we can distribute something that's supposed to be for academic use only. Wait, wait, what? Really? Of course, there's lots of non-free stuff. If licenseans don't distribute it, then pure, or don't download unless you agree with this license, we can. Yes, but if the route restrictions are used, you can't use it in your area. Okay. Well, and as I was saying, there is some non-free stuff like that in science. So I'm not a fan of non-free, right? I voted to get rid of it, but I'm saying that this could be a specific way to at least make non-free more nor well focused for academic stuff, for scientific stuff to say, well, okay, it's non-free, but if you're using at a university or stuff, then... Because, for example, right now, if you're downloading Davion Regular, you can be sure that it's free. And then we could tell universities, like, if you're downloading anything from the task pages, you can run it at the university because it's free for academic use. I don't think that we want to tell them that. I also want to leave, sorry. So I'm not against somehow dividing non-free finer in some way with tags or however you want to do that, but I don't think Davion can say to anybody, if you're in a university, you can use this software because... Or if you're in a... Because that's viability. I don't know. So that idea of Davion promising something about non-free software makes me nervous. Maybe Michael and Jamie and I should talk about this offline. Yeah, we should talk about this.