 So, we're starting a little bit early, which will confuse the people who did the video streaming, and we don't have a mic, which will confuse it even more, but you can hear us, right? So I think the idea of this panel is really to get some feedback from you, from the audience. We know our ideas. We are severely entrenched, but we are able to do two ideas, and I think it would be nice to get an idea of what the priorities are, right? I mean, if we look at the future of geeks, I think we, you know, I can, I will say that geeks are already a success. It is just the start of it, but it's amazing what is happening, and it's, you know, we can build in it incrementally, which is very good for the future, but what should we focus on next, right? I mean, what's, what's going to be, what's the most important thing you think that is going to be, you know, to drive new geeks in the future? So maybe I should ask the panel members first, and then you can react. Should I start? Yeah. Okay. I think I'm going to start straight with our conversation, and we had a couple of questions before. I think the most important. So, A, I think we ought to, we ought to just give a whole round of applause to this room first of all, because this is our second year of this, like at a sub-conference, right? Like the amount of energy and stuff in this room is just nuts. But I think so, one of the things we're talking about the other night is geeks is great. We all love geeks, but getting it in the hands of users is not necessarily very good right now, right? One thing that I would love to see is be able to do apt-get install geeks, or even yell install geeks, I guess, if you're on Fedora or whatever, right? So that one of the big blockers on this is that we have this slash canoe thing, and it's not part of the file system hierarchy standard. Yeah. Yeah. Yeah. So we, so I think that, so I guess the, I'm a little bit weird, I'm going to monologue this, so maybe I have to figure out how to turn it over. The, I would really like to see geeks get packaged in WNR, et cetera, but we have to get over this slash canoe, not being a file system hierarchy standard thing. Now, we could do one of a few things. We could just switch, we could switch over to slash opt, just abandon the canoe thing, but I think that I'm looking out Ludovian's face. I don't think it's going to happen. We could, and so maybe I should hand it over to one of YouTube before I start just, I feel like I'm monologuing, and I feel rude about that on the panel. Oh, I really like listening to you. Oh, okay. Okay. I'll just explain. I'll explain the, so some of the ideas we came up with are kind of successively crazy. Well, the first one is switching to opt. That's not going to happen. The second one is we can do basically what Piotr demonstrated today and just rewrite, we can substitute all packages including, we can basically do a graph of all packages including all the substitutes, all the graph packages and just rewrite them all from slash canoe slash store to slash opt slash store. And then that might make it much easier to package in Debian, et cetera. The other crazy idea is to possibly have a username space. I think this was your idea where people just in their dot accession or whatever end up opening up a username space that basically remaps slash opt slash store to slash canoe slash store. And that's kind of getting crazier. And then the last crazy one is to get it in the actual FHS, but I'm not sure that that's going to happen. So that was a long rant and not really a panel kind of conversation. So I guess I'm going to hand it over to the rest of the group to say, how do you think that we can get geeks better adopted in the world? So I should point out that there, I see a Debian developer sitting there in the back of the room. So maybe from this particular point we could also think about the social approach to it. I don't know. Yeah, so getting geeks into Debian and other free distros is one thing. I think I'm also personally interested in having great use cases for geeks. So we've seen talks and discussions about a few of them. So one of them is high performance computing where I think people are really needing, so it's really a niche in terms of users, but people are really in need of a solution and geeks seems to be satisfying in a number of ways. So that's one thing I'd like to push. And then we have this geeks SD thing, which is pretty cool, I think. And to make it even cooler in a number of use cases, there is geeks deploy, and so Chris has been looking at it before David Thompson also started toying with a way. So I should say what geeks deploy is, I guess. So you have geeks SD where you run geeks system reconfigure, geeks system VM, and you get one machine, one operating system instance. And the idea with geeks deploy is to allow you to actually deploy geeks SD on a number of machines, like on a cluster, on a network, something. So for those of you familiar with KnicksOps, this would be roughly the geeks equivalent to KnicksOps. That's the idea. And so I think the ability to deploy a whole bunch of machines in a reproducible fashion is really one of the killer apps that we could have in the forthcoming future. It's hard to be the third person to say something novel. So I work as a system administrator in an HPC environment. So for me HPC is kind of important. Not just personally, but I think if we can make people, system administrators realize that geeks solves their problems in scientific computing, and they pick it up once, it's likely to change away from it again. So for me this is a personal priority to get it adopted, because as soon as we have people in science depending on geeks, they cannot get away with not supporting it. This is how I ended up supporting geeks. So I know what I'm talking about here. I don't really know if Appget installed geeks is really an issue. If this is really a problem, are there actually people who are interested in geeks who shy away from using it because they can't just Appget install? Can I respond to that? Please do. So what I would love to do is have Media Goblin's default way to get up and running is either that you have a debt package for Debian type users, but if you want to develop, for geeks users they'll obviously already have it for geeks SD users. But if you're developing on something like Debian or Fedora or something like that, I would love people to be able to do geeks-environment-lgeeks.acm. And right now we have to either ask somebody to drop this binary install thing, which I think is not very nice for a lot of people. It technically works, but there's good reasons to feel uncomfortable doing that. And if I could just say, oh, it's just like any of these other package managers you can just install out of the box on Debian, that would be huge. I could just say it's so easy to just pick up geeks, but you have it already, right? And that would be, I know for my use cases at least, it would be big. It's been a while since I used Debian, but I know that Ubuntu people use what is it called? PPAs, right? That's the one liner that you execute to add an additional repository that you trust, and then you can get installed. Would that be sufficient? Or does it really have to be official? I mean, that's another option as well. I mean, I think that that's another option to getting things installed, but I think it would be even better if we could have geeks shipped with Debian itself so that, because not everybody is going to want to edit their PPA list. Yeah, so the question here really is what is the growth path that we are looking for, right? I mean, if you make it easy for people to install software, that's one thing, and I agree with Chris that's possible. The Debian community has been highly resistant to, you know, including package managers in their systems, but they have package managers, you know, for languages, like PIPI and all that. So, you know, I suppose it could be worked on, right? But it's going to probably be a long haul. But yeah, the question is also, you know, what type of user do you want to attract? I mean, you really want to attract users that start contributing to geeks, right? Which tend to be people who develop software. I was going to say, I mean, there is the... I'm just pointing it. Yeah, I'm just pointing it. I'm just pointing it forward. I mean, the other thing I was going to say is that what I really like the idea about this kind of thing that David Thompson has been working on is the container idea, the geeks system container, which I think could be a massive thing in terms of like, well, web service development. I guess for media, but also like for stuff that I'm doing, it's just kind of anything I require multiple services to be running would be lovely to just do it in a container. And I think there are communities out there, I definitely think the community I'm working in is still looking for a really nice development environment. But going to them and saying, okay, you just need to kind of first set up geeks in a complicated way, and then you can use this amazing. That basically, you know, why change the current development environment that they have, which works, but it's a hassle for another one that is also a hassle, and that also works in many better ways, but also just works, you know? So I think in that sense, and those are people that develop software, but they're also users. And it's a niche I think that would definitely we could fill. So many of us talk about how we love that geeks could be a replacement for things like Docker and stuff like that, right? But we don't expect that every user of Docker has to be a Docker contributor in order to be able to make use of those features, which I think is kind of ties in with what you're saying. So I don't think that everyone should, we want as many people as possible to send us patches and to learn scheme and stuff like that, but I don't think that it should be a prerequisite for taking advantage of all of geeks' things. Currently actually this happens already. Many people send us patches. Too many. Yeah. This is a good problem to have, but it actually is also a problem, because managing all these patches, making sure that nobody's left out, that's actually one of the points on our list here. It's kind of hard to make sure that people continue contributing when their contributions don't end up being part of geeks eventually. Maybe you want to say something about this? Because I lost the train of thought. Well, this is something that audience members can help with, right? We could use help with people reviewing patches on the list. And reviewing a patch can, for the first time, actually be as easy as, well, once you get the geeks development environment set up, actually trying to apply the patch and just see if it works on your system, right? And that doesn't require a lot of scheme expertise. And in fact, I think Ludovic and a few others have had talks about plenty of people don't have a scheme expertise when they start with geeks and pick it up as they go, right? So as a call out to people in the audience that's something you can do. Actually, I want to make one more call out for something that people can do to push along one of the things that we talked about previously, which is making geeks deploy happen. If anybody in the audience is interested in getting Geeks SD running on like commodity VPS hosting type things, that would push along our work tremendously and document it. And if you can do that, that'll help us move along in the server space dramatically. And that's something, you know, I'm sure there are a number of people in this audience whose skills could have applied to that. Another one is adding support to continuous integration systems like Travis. If people could just deploy a package, say Ruby, run the software, run the testing environment, that would also be a highly visible project because I think 50% of developers in open source software are actually using Travis now. Should we throw another one to the audience? Yeah, we can ask. Will somebody have a question about the future of Geeks, et cetera, that they'd like to ask or a strongly worded opinion? So one thing that I plused up was talking about the installers and the Travis is some installer that can run as a, like, shell stretch to a batch stretch and can run in an automated way. So the people who are just installing Geeks who want to just install Geeks that would be useful, even on Debi, you know, I think, it would mean they wouldn't have to use the manual if they didn't want to. And also, perhaps, the things like Travis would also be useful because you could just run it first and then do anything with Geeks, possibly. Thank you. Right, so the question is about how we could facilitate the installation of Geeks, right? Yeah, so currently, if you're using the so-called binary table, which is a pre-compiled Geeks, you have to then go to the manual and do each of the steps one by one and make sure you don't forget anything. And that's, yeah, that's kind of not super convenient. And you're suggesting that we should have a script that does that by default. Right. Maybe we'll have an option. Yeah, that's probably a good idea. Actually, it's been discussed a couple of times and I think we probably should do it, although there is the problem that, you know, we are shipping a big binary, which is already, I mean, I can imagine that some people are not comfortable with it. And so if we also tell them, well, just run this shell script and don't worry, it's going to be fine. You know, just the perception could be pretty bad. So it's a bit like curl pipe SH, right? So we need to be careful, I think, about this also. Can we get a quick poll of the room? I'd love to see how people's experiences of getting up and running with geeks slash geeks-istee, I guess, would be. So here's the range that it's going to be. Very good experience, pretty good, and could use some work. All right, so let's go with the, very good, how many hands go, wait, how many people are running geeks, or geeks-istee, can you raise your hands on that first? Whoa, locks, okay. Now let's go for the very good. Geeks-istee, geeks-istee, geeks-istee. Oh man, okay, that means, that's a, that's a product now. Okay, so, now that's six. So let's, okay, geeks first, very good. Okay, pretty good. Okay, how about could use some work? Okay, what about geeks-istee, which I think is a different beast. So, very good. How about, pretty good. How about could use some work? Okay, so I think we're seeing that geeks-istee is considerably harder right now. My friend calls geeks-istee installation experience gentoo for adults, so, you know. I don't know what to say after that, so I'm just going to randomly pass a microphone on it. Yeah, so what's the next topic here? My experience, and this may have changed a little, my experience, like the last time I ran geeks-on-debian is now like over a year ago. My experience was that setting up geeks-on-debian I found easier, but then kind of making sure all the environment variables are set and everything kind of works nicely, that is way harder. In geeks-istee, the installation percentage was a bit tricky, but now it's running, like it's, you know, I don't have to worry about anything, basically. That's absolutely true. So, the complications also rise in different places. Yeah, so what I did, someone built a recipe for a Da Vin package, and I changed that also for Ubuntu, and I just built that and installed it, so that's easier than, like you said, one of the variables. That's easier to just go geeks-istee because everything just works. Yeah, locales is also a nice one. Yeah. True. Geeks does take care of a couple of environment variables for packages that you install, but that's not sufficient, right? There's just a little bit of SSL stuff, for example, or the local, yeah. Certificates, certificates. Yeah, right. It only tells you things for packages that have search path specifications. And is that not right? That's right, yeah. Oh, thank you. And this doesn't cover everything, which means there's always some manual intervention required and that kills it a bit. So, in my experience, we are using geeks as such on the cluster, on the cluster computer environment and on workstations. And I try to make sure to provide a file that people can source, that sets up the environment variables. Maybe we can provide something similar to that. I would really like to move away from the need to do this manually because it trips me up as well, too. Right. As well. Let's do it. Should we have that coffee? So, one topic we talked about talking about here that I definitely want to make sure we don't miss is about community. I mean, obviously, you know, we're hoping that we can engage with the community since we have community in front of us. But I think that there are some things that, to me, it feels like we could do a lot better at. I don't think we're as sufficiently diverse as we could be, and I feel like there are probably, I mean, my experience, I've worked with projects that have really struggled in that regard and that have done better than average, you know, and I think Lisp also has a reputation for being, like, curmudgeon-y people who think they have everything right and then that kind of pushes a lot of people away. And it's partly because, I mean, we do have a lot of things right and so it's easy to spot. But I mean, look at closure and racket right now, which are, like, doing way better than, like, traditional lists. And we definitely could be better. I mean, personally, one thing that I think could be improve things a lot is, you know, if we engage specifically with some groups like Outreachy or something like that, although that would require us having the funds to do that. But I'm really interested in what we can do to improve community and to lower the barrier, especially for the groups of people we don't currently have. I don't know where to go from there, but Ricardo. I have a comment. So yesterday in the main theater, there was a talk on how to improve all-ages access into your community. And one of my favorite suggestions they did is you can bring younger people into your community by asking them to do YouTube instructions because a lot of people can't code but want to share their experience in using something as an operator. So you mean the project could share videos, like giving instructions? Is that what you want? What people remain in your community? You want people of all ages to contribute and then stay. But a lot of times people will come and say, how can I help? And you'll say, well, unless you're a coder, you can't help. So you never want to drive away effort. And so one thing that you can ask younger people to do because it's part of their culture is to do video information. Well, we talk plenty about wanting more video stuff. Yeah, precisely. I had written an item about sharing the workload. It's all about all the kinds of tasks that we have to do somehow. And many of them are non-technical. I mean, we have things like the website, like people posting about what they're doing with geeks, which doesn't have to be super sophisticated. And videos, yeah, that's definitely one thing. Like to help people discover geeks and discover what it does, what it's used for, how it helps. Yeah, I agree that we should try to make it easier to discover what people can do in these areas. Speaking about community, I'd probably like to say thank you. I think we've got a very good community or support. Like the main list is very nice and meeting you here personally is very nice. And what I'm missing from community is like a web front end, like a git lab or something. There are some discussions about it, so what's the state currently about this moment? I can go. So I was talking about this with some other individuals last night, including Alex. We were talking about... So one of the problems is that, for example, before I got into geeks, I hated debugs. I hate it, right? And that's a bug tracking system we use. It's all email-based, right? And I was trying to use the web interface to find things. And I'm like, this is the worst. This is terrible. How do I manage it? Well, then I found out that there's a great Emacs mode, which is what everybody else uses. And it's just beautiful. And it's like, well, now I don't want to use anything else. But this is a traditional, especially in GNU problem, is that we have all these things that, once you pass this very high barrier to entry, it couldn't be better. But you're like, yeah, just like, I promise you, you'll love it. Just run up this mountain. It's very tall, but you'll feel so great when you get to the top. The view up here is so nice. Maybe make videos about using Emacs then. Videos protect me in using Emacs. But I tried for three times to get into Emacs. The third time, I never got out anymore. But the first few times I thought, everybody's talking about it, I should use this too. And it just didn't stick because defaults matter as well. And I agree that Debugs could be more discoverable. I also find it hard to use, actually. And I think I'm the target audience. Yeah. And the mail-based workflow that we have, sending in patches, while it does have a lot of advantages, one of which is that you do not need to have some account on some web application where you have to log in and then click around and do things. You can just send an email. While this is great about it, it also makes it hard to keep track of things. It makes it hard to keep track of patches that you've sent in. But you can integrate this with ORT mode, I guess. But I agree that there's a need for something that combines those two worlds, that makes it possible that we don't have to change too much in the way that our established workflows work for us and that other people find it discoverable as well. Yes, this is actually quite amazing because Geeks as a packaging system is really approachable. It's much easier than doing Debian packaging. I dabbled in that too and I gave up. The amazing thing about Geeks is that you actually can write packages quite low profile, easily get it done, get it tested and run. But then you hit the barrier because you have to submit it to the trunk. I've successfully got some packages in so I'm proud enough to say that it works. But I find it so hard in tedious that I actually don't do it at this point. And the question really to the maintainers of Geeks is can we not find a way that we please both audiences? One is the highly professional, I should say one, that has gone over the mountain and they're happily above there somewhere. But there's also people that just would like to use something like GitHub, submit a patch, have somebody look at it and get some response. It doesn't necessarily even have to go into mainline. The point really is that you want to make it easy for people to get comments and encourage them actually to continue working on those patches until the point that they're actually ready to get it to trunk. So part of the challenge with this is that this is a boy, it would be great to have a big complicated tool that doesn't exist and everybody is busy in the community already with our own big complicated tools that do exist and take a lot of work, right? So I know that, I can't remember what it is. It's a conservancy software hosting thing, you know what I'm talking about. They were really interested in having something that both has an API that you could use in Emacs and stuff, but then also has a web interface and stuff like that. But that project doesn't have, also I don't know if it has a lot of momentum right now. So Calathea, I think that's it, right? So these things are really important and useful. Right now we're stuck between choices that seem very binary, right? Like they're either, you've got a very, I don't know what the answer is for that. Yeah, so regarding tooling, I think there's a kind of a cultural issue. I mean, it's pretty clear that, I mean, some of us are kind of used to their current workflow and everything, so it makes it harder to move to something else in general. That said, I mean, I can understand that it's not necessarily trivial, it's like that big mountain, definitely for people who are not used to it. So, yes, one option would be to use, to have some sort of an instance of GitLab that we could use and test drive. We don't have maybe to switch directly to something, but we could try out something, right? And maybe have two systems at the same time while we figure out how things work and whether it's good for us. And I've been told by an Emacs person that GitLab is not that bad even for the kind of person like me who likes to do things in Emacs and have email and stuff. So I don't know, maybe it's an option. I guess we just need to try out, but it's also about trying out another tool and that's quite a lot of work also, so that's not trivial. I mean, why not have two systems? Call one, you know, the incubator or the teacher or the helper where people actually learn and it could actually be managed by different people. It doesn't have to be the same thing. Right. I think you're talking more about processes than tools, right? Yeah. I think we, I mean, when someone post patches to the mailing list, so definitely way too often it takes time to get an answer. I completely agree. But most of the time there are people who try to do some sort of mentorship and it's, I think it's quite good, I would say, but obviously it doesn't really scale also. And I mean, just because we have two different tools or two different repos, let's say, doesn't mean that there will be double the number of people to actually do that work and that's, yeah, that's a scalability issue. We also don't want to end up in a situation where we have two completely disjoint systems that are very important. Yeah. So, wait, do we want to jump on to, and I feel like we've covered that one pretty well. Do we have other, well, wait. I just maybe want to say like two things. Like, first of all, I mean, I mean, this is not just a geeks problem. I mean, this is a hard problem. Debian has this too, right? But also, like, you know, the project that I work in would work, like, we've got a buck tracker and there are tons of patches that just sit there and just people don't get around to them and especially people who are not necessarily, like, whose first patches it is, who are not really known in the community. Like, there is this kind of element of, like, you know someone, therefore you kind of might look at the patch earlier. There is that element and that's kind of just part of, like, large projects. It is our problem to a certain extent. Tools definitely help. So we need to investigate this, but it's a little bit worth saying that it is. And Mark, I do think that it is easy sometimes to kind of obsess over believing that tools will fix the problem when that's not necessarily true. I mean, I do think we should be working on it, right? But, like, I mean, Mediagoblin has a lot of issues in his tracker and it has a Web Interface bug tracker, right? And we, and if you, the average GitHub repository has no shortage of issues and pull requests, right? So, I mean, we, there's a lot we can do to make it easier, but of course, it's easy to kind of put so much faith in if we can only get better tools. And that especially happens with programmers, right? Because we love tools, right? So, but a lot of it is also social, too. It's very, and it's not one or the other. It's both, I think. You know the thing I wanted to say? Oh, sorry. You go first. Yeah, I wanted to... Sorry, it was... It's a little behind you. It was... We'll do you after. Yeah. Hi, I have a... A minix, is that? So, there's not just lots of other apps we use in minix, and there seems to be lots of work at once. Is there any kind of making this easier to introduce like a standard to be able to use one package from one to one in the other? Or you mentioned Nix, which is already a very, very good tool. It would be a real shame to do it from scratch again. I think... Should we add the Nix language to have a... It's on top of the guy with virtual machine. That's the solution. Yeah. Yeah, so the question is about how we can avoid overlap between Nix and Nix or share work... That's obvious, but sharing work. Sharing work, yeah. That's a difficult question, because I mean... So, does the low-level part is the same, right? So, in theory, we have derivation and Nix has derivation, and that's the same thing. But then, it's not just a technical issue, right? Like, Nix is building a fully free distribution for instance, whereas NixPKG is doing something different, which is, I mean, an important project also, but we have different things and different views on how to do things, like even packaging or that kind of thing. So, we cannot ignore this part of the problem, right? It's not just technical. But then, yes, I definitely think that we should, at the very least, share ideas if not code. We actually already share code. I mean, we've been using the buildDemon from Nix, and it's wonderful. I mean, Nix wouldn't exist without Nix in the first place, right? But, yeah, sharing ideas, at the very least, is something we can do and it's cheap, right? And I'm sure we have a lot to learn from each other and really, Nix people have a lot to learn from NixOS, obviously, because NixOS and NixOps is more mature. So, yeah, we should talk more, I would say. You had a question and we had a confusing point in things. Yeah. It's not a question, right? It's a little story. I learned Nix with a video by people and I had been trying for years. And then, I've been told that people, now it's not called people anymore, it's been both possible. I don't remember exactly, but I've been told that they do not guarantee the freeness of the JavaScript on their site. So... So, freeness of JavaScript is definitely a concern of mine. I... What a lot... But part of the problem is that the web is also a large ocean that I don't have a lot of control over how much of it has free JavaScript. So, I mean, I guess the best thing you can do in that circumstance is contact them and encourage them to free their JavaScript or submit it to a media goblin instance or something. But anyway, are there other questions? I can't really think of that. I mean, if you want... If I just wanted to modify ETC votes, for example, to have an idea or something, and I don't necessarily want to edit and reconfigure to get it done. So, I was wondering if you would accept something I can not, like, pseudo-edit, but, like, we'd say that we'd just edit the file, put it in the store, and just fill it out. Right, so, yeah, I have mixed feelings because... Can you repeat the question? Right, so the question is about how about having tools in Geeks SD that would allow you to quickly hack something as opposed to having to run Geeks System Reconfigure, right? Yeah, so, I think, you know, the functional, 100% reproducible model is inherently very static and a bit rigid, too. Why? I mean, we do Geeks System Reconfigure because we want to make sure we have the exact same system as if we had installed from scratch, right? But at the same time, I'm also a big fan of Gazer and Rapples and life hacking, and I'm also not fully satisfied with the fact that we have to go through this process every time we just want to make a single change. I would like to have something like, if you're familiar with ZMAX, like, Control Meter X, which means evaluate this expression right now. But I mean, it's a hard problem. I don't know how to merge the two requirements. So, I mean, I agree with you. We need something. I just don't know exactly what it should look like. I don't know. I can only say that in my experience so far, I really like to reconfigure things. You're talking about Geeks SD, right? I've never actually hacked on the operating system as it is in the store in order to create some effect. Because I really like the guarantees that a reconfigured system gives me. This is what always annoyed me about traditional system configuration, is that you make a change here and you make a change there and then you start forgetting exactly what has changed and you try to recreate this and there's no way to be sure that you've recreated the exact same steps. And I feel that this should be a thing of the past. So, if reconfiguration is considered an obstacle, we would have to figure out why that is. Is it too slow? Can we make it faster? I'd rather not soften the boundaries that we have. But that's just me personally. I do, however, hack on packages that were already built because sometimes rebuilding everything from source and you know that there's really just one... like Emacs, right? When you're hacking on Emacs and you really just want to play with what's there. I did that before, just making the store writable again. And... But I don't do this regularly, alright? I can understand the need for... I can understand the desire to do this, though it goes against everything that we believe in. I want a tone for this. I lost your credibility. Just an additional comment. Also, a big plus is to keep your system configuration under version control. You just check line, hit commit, and if system reconfigure, it really does give you a second to have more system. I can remember what it is. Yeah, as an example, our build farm, hydra.cnu.org, so it's not running GeeksSD because it dates back to the days where you could barely install packages with Geeks. And so it's running Triscoll, I think, and we've been hacking around on that machine to the point that we don't really know what's going on there. And so we're finally switching to a new build farm frontend, which is called Bayfront, which is running GeeksSD right from the start. And I can tell that, yes, having everything under version control is wonderful. We have the scholar. I wanted to ask something regarding the community participation and precisely about the peer-to-peer project and if it's still on the agenda, the idea of package sharing and which is the rationale which is the status. Is that the GNUNET stuff? Yeah, so the question is about sharing packages in a peer-to-peer fashion. So there was a GSOC project on this topic about using GNUNET's file sharing component and pushing binaries to GNUNET instead of using HTTP, basically. And I think that's something many of us still want to see happening, but it's just that technically there are still obstacles. One of them is that GNUNET doesn't yet have a stable release process so that makes things a bit more difficult. Right, but yeah, for instance during GSOC, the student wrote bindings for this, for GNUNET, guide bindings, and also some sort of proof of concept that would allow you to push binaries to GNUNET and to kind of retrieve them, but it was, yeah, a proof of concept. And again, as GNUNET is currently a moving target, we don't seem to be able to make much progress on these ones. I think we're technically over time, but maybe we can still excuse having at least one more question that probably goes to Ludovic more than anyone. But, you know, oh, no wait, Ludovic and Ricardo, you're both maintainers. But I see 1.0 in 2017 on there. What do we need next to get to 1.0? No, what are the next steps? I can just read it, no. One thing that is, I think we would all agree is bad about Geeks at this point is Geeks pull. And it's also because none of us are using it. So we don't feel the pain as often as we should to change it, and Geeks pull needs to become better. Geeks pull is... Is anyone using Geeks pull here? Occasionally. By accident. Because once you type git pull... No, I'll be based on the documentation. Geeks pull is a very naive implementation right now. It gets the latest version of Geeks, compiles that, and creates a sim link so that the version of Geeks you're using is the latest version. It's actually not even true. Part of that. It's the guide part of it. It's not as safe as we'd like either. Yeah. So for 1.0, Geeks pull should be extended such that not only it becomes actually usable, but we've been thinking about this a lot, we discussed this a lot, that we would like to be able to go back in time with Geeks so that you can say, I would like to have Geeks at this particular version without having to use low level tools like git, checking out an old version, and running make there, and then using that to build an old version of a piece of software that was available in Geeks's history. Geeks pull should be the front end for that. So you can have multiple versions of Geeks that you can switch to and from. And that relates closely to the idea of having channels. To Geeks pull's credit, I think it's not obvious how bad it is to most users, but that's also to its detriment, that they don't know how bad things are under the hood and how much they should be worried about, okay, wait, I shouldn't say that out loud, but... Yeah, so just to give an idea of how bad it is... We're going to scare off half our audience, we're going to run away. But I mean, fortunately, it's not just our problem, it's a problem that we share with pretty much any project that uses git nowadays, which is that Geeks pull is essentially fetching stuff from Git, but it does not authenticate what it's fetching, right? So like we're fetching from Savannah, but if there's a man in the middle attack, you're fetching a different set of packages and you don't even notice, right? And that's a bit of a problem, but it turns out that everyone has this problem with Git. I mean, so there is work, people are starting to realize that it's kind of a problem, we need to be able to authenticate, check out, but there is no simple solution, right? Well, that's the next item on the list. Perfect. And so that's something we need to work on. And for example, people, these two people have been looking at, I mean, there is this thing called the Update Framework, T-U-F, and it's great, but it's really biased towards these tools that have, you know, source on one hand and binaries and repos on the other hand. Like, in...