 Hello everyone. Today we're talking about the question of searching and discovering software in general in the world of computing and more specifically when it comes to the Geeks package manager. So actually a couple of years ago, so there was this guy who invented the World Wide Web in 1989 and 20 years later he gave this TED talk, which I think is quite amazing. I really recommend it in the next web and asking about the linking of data, so it's a good thing to put data there on the internet, but how do we find it and how do we query data with each other? That's a very good question. It's a very general question. I think it really applies to software as well, how we find packages and how packages relate to each other and not just packages. I'm talking about this just now. So so I think what it implies here is that today we have this package repositories, those are app stores and if you already know what you're looking for, you know this amazing software called VLC, so you look it up, you install it and it works. But what if you were looking for a concept? So how to back up my data? If you don't have the name, I mean, this is very tribal knowledge. At last, those programs are basically based on the popularity. What about the rest? I mean, what about those more exotic features? New fields for things we simply don't know. So we like to be able to discover more efficiently. There's something else as well. So I think so do you know, have you ever heard of dot files? So those little configuration files that you put in your home folder to configure your text editor, your web browser or anything. So it's all a program and typically those five configuration files are stored in what we call this dot files repository. Quick show hands, how many people here have ever written some configuration file on a computer? Okay, it works. I'm a bit stressed about this because the one with the handle would have been a big part. So I actually did try this query on Github and it returns some 130k, 130,000 dot file repository on Github. I think it's insane. I don't know what you're thinking about it. But if I don't know if you say there's an average of a thousand lines per repository, that's some millions of lines of code that are well used by individual people but not really put to the common good out there to be to be reused and to be shared. They essentially don't find something personal. They are not really those general, they don't take this very general approach to distribute programs. So I had this intuition that maybe we can start with an entity's craziness and start being a bit more general and by this, I mean that essentially what a dot file is that it implements a particular workflow that you have. For instance, if you think about backup, you maybe write this backup script that we call some SSH, VPN connection, whatever, and use all same different sort of data. And really, I think we can be more general than that. So if you have this framework for services, so just like system services, but maybe also user services, so essentially those little declarative snippets that tell you what you want to do. And once you've gotten that set up, you can really really share it with everyone else. I mean, this becomes very trivial and much less personal. I'll give you an example. So and using some X expressions, we could declare at the global level. So for everyone, we could declare this a backup service type. And then program it so it takes different fields, host a port for the server. And what would be very interesting here is that you get those two fields. Austin plus VPN could be the way you want to do it. And this is where you can specialize. And this is where very obviously you own folders. So that's also where you specialize. But what's really cool about this is that the specialized part is only three lines. So you don't need a huge script or multiple scripts actually to bundle together to get your features running. You can do, we can be more generally distributed so that we save everyone work in time. So how do we do this? I think there's another talk happening later about system D and home D. It's very similar. So we already have this thing that's working or why not allow, since with this room, why not GNU Geeks and GNU Shepard? And what I find great about this is that you can install GNU Geeks with Shepard on any system or GNU Linux distribution. And why it just works? So it's quite universal. Everyone can use it. So it's very easy to share. And what's also particularly interesting about Shepard and Geeks is that they can be tied together in the way that when you declare a service in Shepard, it will automatically drag the required dependencies. So with my previous examples here, from my user.files, I can just put this service there. I don't have to install a VPN program or R-Sync. It will do it for me automatically. So I don't have to care anymore about the implementation details, which are the underlying programs. I don't care about this. I want to get the job done. I want to do the backup. That's really what I care. The rest is just details. So back to, let's leave the service to the site for a moment and back to the packages. Next, next to us, Goring distribution, this thing has some 40,000 plus packages. It's pretty huge, right? Geeks is getting there very slowly. So with some 12,000 packages. So imagine, I mean, do you really know this package? I mean, have you ever brushed through the list? It's really hard to find your way around. I mean, you probably, you can probably browse the list by the programs that you already know, like VLC and so on. But what if you have to discover something? I mean, we need a good search system. We need to link the data so that we can explore more humanly, more efficiently. So it speaks to us. We're not machines. We cannot browse 40,000 packages. So with some promise, you know. If you've so a lot of package managers have support for searching files within packages. For instance, if you know the mercurial VCS, a version control system, the executable is actually called HG. So if you're looking for HG, you might not find mercurial or vice versa. So you need a system that supports both. A lot of package managers actually support it. Geeks doesn't. But not all of them are smart enough to have this search system that will actually look it up both in files and in the description or the package name and all those things. In general, you do the file search separately from the package search. I think we could blend those two. So I think and since this is missing from Geeks, I think we can implement this this way. That would be pretty cool. Another problem is that well, so-called Gen2 use plans. If you use Gen2 or on next things called the package overrides. So we may have different features within a package itself. So for instance, you may build a browser with different types of backgrounds or maybe GTK or QT and then you don't really get the same package in here. I mean, if you have one build with some features, another one, I mean the same package with other features, then we have a different type of granularity. We want to also know about the features that are at this level, at this granularity level. Then and one that's complex topic actually, but it would be nice to be able to just like for files to be able to search for features within programs as well. So I was talking about search before and that means that we need good search. I think a lot of package managers don't have good search and maybe it's easier to just find out, to just do an internet query to actually find what you're looking for. And that's a problem. We should be able to do it from the solution itself. So I think we need good tooling, good user interface, and in particular good way. I mean, we want to make this very accessible to all of us, not just common line gurus. Then, so going back to link data, how does it work? What is link data when it comes to packages? Because they don't necessarily have, they don't, the package itself doesn't know about a relation with another, except for the dependencies. But what if the two video players, MPV and VOC, well, maybe they're not related on the software level, but are related in the meaning, in their purpose, right? They're both video players. So here we need a system to have some human input that says okay, this is how we categorize things and they belong to the same category. So you can start adding this humanization of the search domain. Among packages. Then, well, then those are very typical features that you get from app stores, etc. You get a number of downloads, the ratings, all those things. Why does it matter? I think it actually matters because it gives us additional data about how much a program is used. So, for instance, the number of downloads or ratings, maybe we should focus a little bit on the most popular package because we want to make sure that they work. But, actually, more interestingly, we want to focus on the least popular package because if we have it and only a few people care about it and it breaks, well, chances are that no one's going to fix it. So with that kind of data, we have a better perspective on what should be, what should get special attention. The last, on the last entry here, tags, put it with a question mark because we would tend to think that maybe tags should belong to the package metadata, they are not human input. You would say like VSC should have the hashtag video tag. But maybe not. Actually, the problem with tags is that they're essentially very subjective. They go with time with different fashion. So maybe today we'll talk about cloud. Maybe this term will go out of fashion in five years. We'll talk about something else. So the word cloud will not be meaningful anymore. So in that sense, I think tags should be very dynamic, very volatilizing. So what does it mean to be searching? I think so this is basically combining everything I said so far into one single interface. So don't separate the search for different components. We don't want to have a separate search for files, for features, for the community data. We want to just write my package manager search, or even from a nice GUI. And write, well, your query, I mean, I want to back up my data and issue return the relive and stuff. And that would be really amazing, right? You don't have to care much more about it. So for so for the further, when we go to the detail, implementation details, so WikiData, do you know WikiData? Show hands. Okay, so it's surprisingly not so popular. Well, what here? I guess we have a select audience. WikiData is this amazing project where it's a Wiki, by the Wikimedia foundation, where everything, every object, every entity, every concept on the planet is indexed and has those properties. So typically, do I have the words here? Yeah, if I do this, it will appear. So this is the WikiData entry. So it shows the languages, different terms, the kind of instances, if it's software, library, video player, the logo, you get all those different things. Inception date. So what's really cool with the WikiData, I said, well, it's a Wiki, so I mean, if it's free to edit it, and you can put all of those human inputs in there. So that could be a very nice interface that we could exploit to actually make use of this community-driven data. Sorry. Next, well, that's not to myself, sort of. So how do you make this search engine? Practically, package manager search anything and it finds what you want. I think it's something really smart here. Zapkin is a nice implementation that uses a lot of those inlinks between the same words and so on. So it allows you to actually support just the meaning of what you're trying to search and return the most relevant result. It's pretty amazing. If you don't know Zapkin, check it out. And if you do something better, please reach out to me. So the good news is that I'm actually working on it. I've received a grant from the NLNet Foundation and I would like to address more or less all the points I've mentioned today. And I would like to do it on Geeks because I believe that it's a very good package manager and well, as I mentioned before, it's universal. Anyone can use it. So I'm not doing the work for just a subset of the distributions. I could actually apply it to everyone. Yeah, sorry. So that would be, this is basically to sum up the five different steps that would be to implement all this. And here, if you're interested, it's a little bit of a side comment, but if you're interested by the NLNet Foundation, if you're working on a free software project, check them out. They have quite a lot of money. So you would be more than welcome to contact them. And last but not least, if you want to follow up on Geeks Development, I'll be there. And this is my personal website, my blog. I will be posting there, my progress. And I hope that we'll be successful. Thank you very much. Questions and please repeat the questions. Yes. That's a very good question. I don't know. And I think that, okay, this is not part of my work, my work project. I think this is a central question. How do we publish programs on the internet? Yeah, we can set up a repository, but in the end, if no one knows about it, how do we find it? Yeah, that's a good question. I'm sorry, I don't have a good answer to this. To actually feed the results into Wikidata rather than just use Wikidata. Yeah, that would be really good as well, yeah. So maybe have some bi-directional, yeah, for a definite. All right, thank you very much.