 Okay. Enrico, your subtitle is redundant. Last and ultimately in the same thing. Yeah, but that's rhetoric. Which is redundant. But it is cute. Yeah, but it is cute. Yes. We can talk about your DPL. Can you start? Can we start? Okay. So let's welcome with us. One of the man with the funniest talk you will ever meet here. Which is not true because I have a hangover from last night, so I'm going to be boring and fall asleep in the middle of the talk. So one of the funniest men ever, you can visit the talk at least for the half time. Telling you some nice stuff about DevTags and how to organize many, many packages and search in them. Please a warm welcome for Mr. Enrico Sini. Hello, good afternoon. Welcome to the DevTags presentation, title acute presentation of DevTags, subtitle of course the last ultimate step towards total world domination. Which is, well, just because it's my compulsive titling, it's actually the best way of knowing what's in Debian without becoming an FTP master. Well, there's actually another better way, which is being the DevTags maintainer and then you tag packages and then you have to know about everything in Debian because you have to, well, okay. Because later, the contents of the talk, I will talk about the current problems that need to be solved. It's very easy to talk about the problems, so I will do my quick ritual and then I will explain to you the theoretical background of DevTags and then I will do a demo of what's around. So let's get to the problem with some flame war, like shit, shit, shit. So we have 17,068 packages. Actually, we don't have that much, but when I created statistics, that's what it decided to do. Which may be a bug in DevTags, but that's going to be something else. And binary packages. So it's pretty hard to find out things. When you get the list, like what package do you want? It's my favorite question in Debian. It's really an easy question. But it's one of the ones just hardest to answer. And compare that with this problem that brain tends to be, tends to like go away when you have more than 7 plus minus 2 items. That like 17,000 is a bit bigger than 7 plus minus 2, which means we will never have a full understanding of the entire Debian archive unless we do something about it. We have sections. There's 33 of them, more or less. But that doesn't really help because if you divide 17,000 by 33, supposing you distribute things equally, then you have way more than 7 plus minus 2 anyway. And then there's categorization problems like you can only have one section per package, so where do you put open office? I mean, is that... It does pretty much everything. Or last night there was the problem of how to categorize a kernel driver to access digital camera. So does that go in graphics? But it's a kernel driver, so that maybe goes in admin, so that's the idea. Or we can do full text searches. That's some example full text searches I did. So if I look for a web browser, I get 197, which is more than 7 plus minus 2, like 2 more. Text editor, 170, and if I look for a GNOME text editor, I get nine results. Three of them, they're not editors. Six of them is Emacs. And then if I upcache search image, editor I get 22 things, but not Gimp. So, well, they kind of work, but could be improved. So that's my best favorite way, which is word of mouth. So telling each other what's the best package and we can trade like we do in Italy with stickers of football players. I don't know if that exists only in Italy, but when we are children, we have like albums with empty spots and you buy the stickers and you put them and you have to complete it and trade with friends. It's pretty nice when you are like 80 years old. So we can do the same, which is fun and easy. So that's my list of favorite packages. I go, what? I didn't understand the questions. You said they're reported out. Right. Okay, so you won't understand it. So I can fix it. Two, four, six, seven. Line. Yeah, actually, well, cappuccino is the most important and polygen is the second most important. So now you all install them in your laptop, right? Okay. So word of mouth or black magic. You can do searches. Okay. You can search, but does that amplify? No, video people, I'm not hearing my voice. Do you hear my voice from the speakers? No, I mean, everything okay. So we may have a problem with the recording. Right, okay. Hi. I can use this, no problem. Okay, better like this? Good. So you can search packages by black magic, like with some, which may work, but may not be that intuitive. So let's see what we really need. So, well, the main task is narrow the package list down to about seven plus minus two to be compatible with the brain. Now, the capacity of my brain is actually three plus minus one because of the alcohol. So if you ask me a question, please don't say more than three or four words in the question. And so, narrow down the package list. I personally don't care about an exact match. I don't want a system that knows what I want better than I do. I only want to narrow to a list of packages that I can actually read without spending the weekend on it and which has a high likelihood to contain what I'm actually needing. And we need to describe packages from different points of view since we have different kinds of users. So you can imagine that the priorities of a developer is different than the priorities of a lawyer or a scientist or a kid. And so we need different points of view. And there's an insane variety and diversity of Debian packages. We have Debian for dentists with Odonto Linux. Maintained by a dentist, which is a Debian developer and also is from Rome. And he's the dentist of another Debian developer. I so much love this. There's a Debian developer who has a dentist who is a Debian developer. It's like, fix the bug. We have things for quantum mechanics and painting programs for children, for kids and lots of things. Huge variety which gets it quite hard when you go to categorize them because it's really easy to categorize like image editing plugins. You have already a context. You're talking to people in graphics and so on. It's less easy when, you know, there's pretty much everything. And Debian changes continuously. We also need something which can cope with evolving things. Like, for example, the sections, they need it to be updated from time to time. But if we do like a major redesign of sections, we need to go down 16,000 packages to fix everything. So, I mean, these actually needs to be taken care of. And then, well, in order to be complete, I need to... Well, we also need many other things, right? But this is what we generally need for DevTex. So, let's see how we manage. And that's DevTex theoretical foundations. There was an Indian in the room, I think. I remember, maybe not. Okay, well. Anyway, I'll thank him later for having given us. That's the first DevTex developer. I can't read it. But I'll... Well... Shiala Ramavita Ragnartha. Okay. Okay. Manoj, what's the name of Manoj? Manoj Struvastava. Okay, good. We have a good leader. And we used to have a developer named Vaidhi Naitan Mayurangel. Okay. And how do you spell Nikhil Mayur? We're recording in your pronunciation. Okay. Just a punch. All right. So, I should, like, read it for the fan at home that will, like, watch the video. So, it's Shiali Ramamrita Ranganathan. I tried. Well, okay. Actually, I didn't... I mean, that was not my intention to have fun with him because it's, like, invented library science. And it's been, like, quite a... quite a person in the categorization work. And, well, that's... that's a loss of library science. And yesterday, the gradient was different. It looked really neat. And now it looks really stupid. I wanted, like, to set it on stone. I've been getting a nice gradient, but it's gone. Anyway, this is Ranganathan's loss of library science, which I just replaced books with software and library with Debian. And we have the loss of software library science. So, it's nice to go through all of them. I hope they're readable, especially the last one. So, software is for use. I mean, it's not just to sit there and to say, like, I made the software, which happens to be the case for my Debian packages, but, well, software is to be used, so you have to find it, right? And every user... to every user is or her own software. There's not a software that fits everyone, and so everyone must be able to find their personal software. So, personality of the user is part of the search. And every software has its user. Well, that's, like, the opposite side, but, like, software implies some kind... Different software imply different kind of users. You have to save the time of the user. I guess you like this one. And so, you need to find things quickly. And Debian is a growing organism, so things need to adapt. And so, what it came up with is faceted classification. It's a bit scary, but, right. So, which is... That's one definition I found. It's about using clearly defined, mutually exclusive and collectively exhaustive aspects of a subject and use them to categorize. So, basically, you find different aspects of packages. And inside every aspect, you have categories. So, there's not a unique namespace of categories. I do it, like, programmer style, the same namespace. Every namespace is related to an aspect and describes it. So, we can have, like, what's the use of the package? So, you will find categories like editing and showing, viewing, playing, so on, and gaming. And then, we can have the package... What kind of data the package works with? And so, we have, like, image, text, source code, and so on. And then, we can have what language the software is implemented in. And so, that means, with a c, c++. And then, we can combine all of them to create combinations of these different aspects, allow us to categorize with an insanely huge amount of possibilities. Because then, we do the combinatorial composition of different dimensions. It's like different dimensions. And so, we put the package in a multi-dimensional space. It's pretty neat. Well, anyway... There's many sets of categories. One for each aspect of packages. And so, we categorize under different points of view. So, that's me under different points of view. And we do the same with packages. Thank... Well, actually, this one is fake. This part here. But it doesn't show, so I have a good dentist. But she doesn't run Debian. I'm working on that. So, depth tags. We have different aspects. They are called facets in depth tags. This is an example, a list of facets. Actually, it's an extract. It's what I said before. So, we can categorize what the language that it's implemented in. It's really useful if you look for code examples. And the kind of user interface, common line, x, curses. They're all of the package in the system. Is it an application, a plugin, a theme, a library? And the purpose of the package, what does it work with and many others? Facet is not a category. They are containers for categories. And they contain tags. Well, tag is the same as category, but it's shorter, which is really useful when you use it a lot, especially in code. You just have to have, like, shorter class names. And this is an example of the different categories for roles of packages. So, you can see, like, if you look at what's the role of the package in Davion, that's the possibilities you can see. The whole set of facets and tags is contained in the vocabulary. It's a text file, which lists them. And the vocabulary is maintained on subversion by the people subscribed to the members of the Alliov Deptags project. And Deptags allow to have more than one vocabulary and merge them together, which is a really neat thing we're going to see later. But I just wanted to point out that they can be merged. And then a tag database means what are the tags associated to packages that can't go in the packages file, because I want to avoid being, like, fleeing to death, because that would increase the packages file by another, at the moment, 700 kilobytes. And then it would require, like, constant changes to the packages file, because tags change pretty often. So it's external. It's maintained in this place for historical reasons, but it still works pretty well. It's editable by everyone, so it's really open to denial of service attacks. But we do backups. But we made it wiki-like just to have a get data as much as possible, as fast as possible. So that's the tag database. And now those were the fundamental concepts. They were less than seven. You will appreciate that. Fewer, not less. So now I can show you some depth tags things. I did. You want a double check just in case it crashed? The question was if I did start the VNC screen-grabbing system, which is kind of internal, so I didn't actually. All right. There's, like, two main, well, three, well, two, main depth tags programs at the moment. Three, actually. One is depth tags, unsurprisingly, which prints a nice help in common line when you invoke it. The most important, well, one of the important things with depth tags is depth tags update. This will download, it will require root and download an updated version of the package database. It will download it from its ETC depth tags sources list, which contains tag sources. It would be nice if FAPT would, like, ignore things which don't start with depth, so I could merge it in apt, but maybe it's better like this. And you can add more things, and they can be merged. We'll see an example of it later. But I still like this merging thing. I consider myself really smart for having conceived it, and you can do depth tags cut, and so you can see, like, package, tags, easy. You can do depth tags, grab with tags, and then you get... And grab is quite nice. You can do things like... And then we get raster image editors. Well, maybe you want to see it more visible. That's image editors. That were, yeah, well, image editors. And how many people use GNOME? How many people use KDE? Damn, it's even. T-W-M. T-W-M. Okay, well, that's not... I can do things like, and not... I run GNOME, so I say, and not GNOME, so that balances a bit. And I don't want the GNOME ones, and so that goes down, and then I can say that I want and interface X11. And you see, it gets down and down and down, and you narrow, and you get to a nice number of seven. Got it. So this is already... Well, yeah, that's another one. Okay, the question was... Thanks. The question was, well, it's really nice, but about the complexity of remembering all the 400 depth tags. Which is a really good question. But we have, like, graphical interfaces for it. So that can... Well, so that's a use. You can actually do something really hardcore. Install all of them. Okay, sorry. Yeah, okay, I'm not rude, but I don't want to install them, so that's good protection. When you are in Hangover... Oh, that's apt, it has it. Actually, it has dash s and then about five synonyms. Okay, sorry, the question is, apt has a simulate switch, and so depth tags could do the same. I didn't know it, thanks for the question. That will probably be implemented. File a bug. And then you can, like, search tags and, like, these sort of things. But, anyway, depth tags can do, like, other cute things. Well, grab, install, we've seen them. You can generate a to-do list for you, which is a list of the packages installed in your system that have no tags yet. So you run depth tags to-do and then you get to work. You have installed them, so you know something about them, right? That's shame on me, because I still have work to do. And you can do, like, crazy stuff, like, generate a list of tags associated to maintainers. I can, like, get every maintainer and get all the categories associated with all the packages. And then I can do, like, let's pick a random maintainer. Then I can do... Props for avoiding the useless use of CAD. Okay, so... I can see who are the maintainers related to Brandon. Like, they maintain something sooner. Nothing related to me is worth tagging. So, I can do that young developer matchmaking. Oh! Scary, scary, scary. None of those people are here. David, do you maintainers? I can actually do matchmaking with groups of maintainers. So, it's like, if we have a group of Debian developers going out for drinking, who should they call to go out with them? I mean, that's one of the possibilities of depth tags. You see, the data is pretty flexible. Let's see if the cabal is reflecting that. Okay, later. There's no cabal? Repeat the question. Okay, the question was not repeatable. The question was very silly. I don't repeat the question because I can't. For because, like... You would be struck down. Yeah, that's like... It mentions cabal, so... The question doesn't exist. And I can do other crazy stuff. I mean, this is like the neat, stupid things to show at conferences that I like to implement much more than useful things. This will go and have a look at all the packages I have installed in my system and look at the tags kind of around in my system and then looks at the not-installed packages and figure out which are the packages that I may be interested in installing. The highest, it's probably not too bad. That sounds like a good guess. Yeah, well... Okay, that was not the question. That was like, well done. Repeat. Brandon said the result is not too bad because I actually run GNOME and I have per-stuff installed, so it looked like it would fit. Okay, back to more useful things. Let's go into the word of interfaces. If it doesn't suck, hold as usual, okay? That's depth tags edit, which is a GUI interface to the depth tags. You can do searches and you can do tagging. So you can get, like, see a package and then add categories to it just in the blink of an eye. That's much more than seven plus minus two. But we are, like, creating funny algorithms to cope with that. And you can see that it starts with your maintainer email. It will pick it up from that email environment variable like to get you to work as soon as possible. If you are not a Debian maintainer, it defaults to showing you installed packages with the same idea that you should get working. So here's the entire list of 16,900 packages. We can try to do search. Again, image editor. So we want to editing and we want to add an editor that works with images. And we're down to 37. And then we can see, you can see it narrows down. So once you get the search started, it will help you a bit to reduce things. So I can see that I have common line image editors and X11 image editors. You are curious in the common line. And that's the common line image editors. This is really tagged randomly, probably. No, not really, okay? And, okay, that's the question. Some of the items didn't appear to have descriptions like X11 and Debian EDU. Was that a bug or did somebody just not write a description for the tag? Okay, the question is, some of these items like X11 don't have a description. True, that should be added, but not necessarily. I mean, the X11 was a test we made and that's probably a facet which is not going to stay. Because we have like interface X11. So that's maybe redundant. That's why no one has been caring too much about it. And the Debian EDU one without the description, that's another kind of experiment. So the mostly used ones, I mean, the ones that we are a bit more sure about, they get a bit more care. And so we narrowed down things and we can also navigate a bit more fluidly. So I can see what can I edit with common line tools. With common line tools, I can edit 3D models, any file, plain text, breast image, vector graphic. 3D model editors for common line. We have it. And then what are the interfaces I can use to edit 3D models? I've been welcome to take questions possibly at the end because of time issues. Exactly. At the end and outside because they will shut us after the talk. And so on. So you can actually navigate back and forth adding and removing categories. And it gets to be quite nice. All right. More things that can be done. There was the Debian EDU facet that's not found in the central Debian tags that we maintain. It was an experiment I made with Petter two years ago. And we used the Debian EDU distribution generation files to automatically get a list of categories. And I merged it. I told you it can merge vocabularies and tag data. So that can be merged in. And so if you make a custom Debian distribution you can have your own categorization for your users with a language they understand. And that can be merged and blended together with the rest of Debian stuff. So you can go like Debian EDU, like logic games. That's already quite narrowed down. And then find the common line logic games. Well, there is actually a common line logic game. Even though I don't play chess on the common line but maybe people can do it. Debian EDU comes from Debian EDU. Like Debian EDU decided it's a logic game in a school environment. And the Debian people instead said that has a common line interface. The two things are merged together. And so it actually fits different custom Debian distribution things. This is one of the neat experimental features which looks very promising. Also other entities can provide more tags. Like GNOME people could do GNOME tagging and get them merged in or something. And I also can have personal tags. So there was the Enrico thing which is not here anymore, right? Bug. No, actually it's a bug in my brain. Okay, well I used to have an Enrico face it here which would list interesting, must look into it, essential. And I would use it to mark packages. Maybe I see the description. It's nice but I don't have time now. So you can imagine that integrated into package manager to allow you to actually put your own remarks on packages and use them to actually search. Or you say like install all my own essential packages like cappuccino, polygen, kause and so on. And that's another neat thing that can be done. If you happen to run that text edit, there's a hidden menu up here. And it can show you exoteric stuff. Just a random click on one and it's basically packages that need working found with automatic heuristics. So this was all the ones which have no tags at all and they are just waiting for you to say it's user interface toolkit is GTK, right? And all we can do other things like all the ones that are using some user interface toolkit but nothing is known about their user interface or they are linking with some user interface library but we don't know which language they are implemented in. So we're starting to develop heuristics to find problematic spots and there's an automatically generated HTML big statistic thing that I don't run now because it takes like five minutes to complete. And you can go there and you see the packages that need work. You click on them, you go directly to a package browser application and you can directly add tags. So that's pretty neat. After you add tags in that tags edit, there's a file, mail changes to central database. Easy enough. And you contributed to tagging. So that's the other tool that we have at the moment. There's also package search. There was package search. It's been kicked out of my system by the Upt6 transition. And now I re-uploaded it. It may be kicked out again because of the GCC transition. That's written by Benjamin Mizzang, I think. Something like that. And it's another package search tool that uses depth tags to look for packages. There's even a super, super experimental thing which I just... Oh, by the way, we have bindings to Python and Perl if people want to play. Every functionality is in libraries. And there's SWIG wrappers. So actually, if people want to play in OKmail, that can be done. I mean, the bindings can be generated. And this is another example which maybe works. After Linux tag, I've been talking with usability people. I mean, at Linux tag. And they gave the idea of having an improved full-text search. So I can look for image editor and sacfold. Okay. That spells GCC for transition a little bit. And, like, well, the idea was that I can start from a full-text search, which is easy. And it will already narrow down a lot, the list of packages. And then I see the tags, the resulting tags, and I can do more like these, not like these. So I can go by example like, yes, I want a common line. No, I don't want shared libraries. And that would narrow down your list, and it would also compute related packages. So image editor in Uptcache search wouldn't show GIMP. But in this case, I see other image editors, and I see that GIMP is related, and I put it back. So that's, like, new ideas to implement search in Debian. There's a lot of experiments needing to be done in that, waiting for fantasy, mainly, because you've seen the data is really quite flexible. And then I go to the conclusion, I think. It was five minutes left. The question was, there's five minutes left. So the things you can do as Debian developers is tag your packages, which is kind of hard to begin with, because there's, like, a lot of tags. But I direct you to some tags you know, and possibly you are the best one to know, like implemented in, the whole implemented in, face it, like what language the package is implemented in, you know it because you are the maintainer of it and you compile it. And so no one better than you can enter that data. So, I mean, even if you don't do it complete, that's a good one. Adopt a face it or tag. That's, we, you can not only adopt packages, but also face it or tag. For example, if you know a lot about, like you're an artist, so you know about everything, messing with images, you can adopt the works with image tag and make sure that it's accurate, that all packages which have to do with images are actually having that tag. And, well, also, like helping, like the DevTags people could be useful, like the website is totally underdeveloped and the DevTags packages need, well, they are very well developed because actually I do it. They're very well maintained, I tend not to have the time to maintain six packages which depend on each other. And so, or maintain a language binding and play with code to find out, like, smart things with interfaces and so on. That's about the play with code. There's a nice play with code thing. Don Sechfeld, please. Thank you. There's many great ideas needed to be discovered. So, we see this is very long, right? It takes a while. I clicked, I swear. No. That's much less. And there's an algorithm that can compute that some can be included in others without losing information because it looks at all the packages and can figure out that, for example, games has been hidden because I can say I use it for gaming and so I don't lose much information if I take it out because all packages which have game tags also have use for gaming. It's used for gaming tags so it can figure out that it can safely remove it. And then when I go into use for gaming, then game will show up. So, that's another... I mean, all ideas that it's a really nice experimental area. I actually would like to work for a university and be paid to do it and publish lots of papers because it's a really fertile research environment. And, yeah, play with the code. Even if you write a silly application to do very few things, it's really helpful because I have someone testing my code and give me feedback on the documentation and on the API. And those are resources. There's a mail-in list, really friendly, because I moderate it and finally I kick it out. I should ban, actually, Andrew Suffield from ever subscribing to it. But I want to give people a second chance. Is Andrew Suffield here? No, I haven't been insulted yet. Right. Okay. And there's a website which does a decent job of listing resources, at least. So, the talk is one minute. Just because he's the DPL, but there's another question I remember, but, okay, you have the mic. Do it. Well, I just had a couple of comments. One is I did... This is impressive stuff, first of all. It's quite seriously because we've had for years a serious searching problem. When I first joined the project, or actually when I first started using Debian, sorry, back in 1996, I was already overwhelmed with the number of packages that were present at the time. It was much larger nine years later. So, this is exciting looking stuff. And, second of all, I want to congratulate you, not entirely facetiously, on managing to launch this project and bring it so far along without the involvement of E. Ray Oskaral. And maybe some of us here will remember what that name means. So, I'll let you have the next question now. Okay. Thank you. You don't know him? No. Okay. Count your blessings. Close it. We are really out of time. Perhaps you can answer any other questions outside. Thanks anyway, Enrico. It was again funny to listen to you. Thank you. Thank you very much. So, that's it for today. Tomorrow we will start at five past nine with Debian Development in the Third World dating America by Gunnar Wolf in this room and in the small room above called Appealing Presentations with Latex Beamer by Andreas Trille. So, see you soon in this murky. Please get out of here as fast as soon as possible and please don't forget your bottles and your other... trash. Thanks.