WEBVTT 00:00:12.000 --> 00:00:59.000 This is netstack.fm, your weekly podcast about networking, Rust and everything in between. You are listening to episode 27, recorded on the 5th of February, 2026. In this episode, we speak with Daniel Stenberg, founder of cURL and president of the European Open Source Academy. We reflect on FOSSDEM 2026. European technology policy and his talk, open source security in spite of AI. Exploring what AI means for maintainers and the long term resilience for critical infrastructure. Let's begin. 00:00:59.000 --> 00:01:22.000 Welcome to another week of netstack.fm Today with me is Daniel from Curl, as we want to talk a bit about how he is dealing with all the AI evolutions or as well as how his view was on FOSDEM, what he learned from it, and also the new open source academy that they have started. So welcome, Daniel. 00:01:22.000 --> 00:01:24.000 Thank you, good to be here. 00:01:24.000 --> 00:01:57.000 Yeah, so you just came back from FOSDEM 2026 and for me it was the first time I attended since 10 years ago and it felt like the first time and I was even a bit lost. only like after some hours that I discovered that they have an application where I can easily find where I have to be. And then I also noticed that you published even a guide or you started a repository for people to help them on how to get the most out of FOSDEM. Can you tell a bit about that repository? 00:01:57.000 --> 00:03:15.000 Yes, so I started that just basically because I realized that a lot of people had kind of their good tips and good first time advice to people to get to FOSDEM and I realized when I saw a lot of those good advice and good tips, we should gather them at one place. I mean, potentially that should be on the FOSDEM site. I don't really care, but I figured I just want to, it just struck me that we should gather all those good good things to think about when you attend FOSDEM because FOSDEM is a conference that is slightly different than a lot of other conferences in the spirit, in the chaos, in the size and all the parallel tracks and all the people and everything. I figured I would instead of, know, expecting someone else to do it or wait for someone else, I fired it up and asked around, added a bunch of things I could think about and then I stole some other good tips I saw and then opened up and people have started to contribute. I think it's getting there. Now it's a good bunch of advice. I actually met several people at FOSDEM who thought it was at least a good collection of ideas and things to read about, especially I think as a first timer. 00:03:15.000 --> 00:03:22.000 And is there some like, can you pick out some advice that you think is particularly surprising or that you think people should really know about? 00:03:22.000 --> 00:04:01.000 Well, is sort of earth shattering or completely surprising. It's mostly like to think about maybe how to dress or as I talked to someone who was so surprised, know, no one is wearing name tags at Fostum. And to me, it's like, of course not, at Fostum, why would you have name tags or anything, right? But yeah, you have on most conferences, you know, where you pay for, get a... You get into the entrance, you register and you get one of these things. But no, not at first time. You just come and go and say, please, no one knows who you are if you don't want to. And stuff like that. 00:04:01.000 --> 00:04:05.000 Yeah, I mean, I do like it, but yeah, for me it also felt a bit chaotic. I mean, I do like it, but I... ⁓ 00:04:05.000 --> 00:04:31.000 Yeah, I mean, I totally enjoy it. But a lot of those things are actually, and especially when you've been there a couple of times, they feel natural. Yeah, that's FOSSTEM. That's just how we go about it. But sometimes I figured it could be just to help people to get into the spirit better if we provide a little just explain a little bit more what to expect and how to maneuver the FOSSTEM experience. 00:04:31.000 --> 00:04:46.000 Yeah, I greatly appreciate it. You've been attending FOSDEM for many years now and when I talk to most people who have been attending for so long they always tell me it didn't really change. Is that also like your opinion? 00:04:46.000 --> 00:06:16.000 Yes and no. mean the spirit, the chaos, it's certainly the same pretty much. It's always been chaotic and you know open and friendly. So and chaotic, by chaotic I mean that every room is separately organized so it feels like you you easily get collisions because room A and room B they have no coordination. They might be very similar in So if you want to go to between A and B, you would imagine that you could easily pick up talks in room A and then talks in room B, but they can go however it wants. But yeah, in that spirit, think sort of it is the same, is in the same spirit, the same kind of things, but it has grown. I think it has grown quite significantly. The first one I attended was 2010. It's grown both in number of attendees and in size and I think over time they have expanded to use more parts of the university campus and more of the bigger rooms. think back in the 15 years ago they used more of the smaller rooms and I think it's a good thing that they have over time gradually upgraded so less teams are in the very small rooms because there are a lot of attendees now and we want as many people as possible to actually be able to get into the rooms when they want to see a talk. 00:06:16.000 --> 00:06:36.000 Yeah, I even saw that there were some buildings where they had like around European policies and this and that. Is that also then something from your like, I mean, in the end, you're like quite an authoritative position within the open source community as you've been there so long, you work on a very fundamental piece. Is that something you're also involved in or? 00:06:36.000 --> 00:07:56.000 Yes, I am. I mean, yeah, I am involved in a little bit of that. Not that much at FOSDEM, I think. But yes, ⁓ I think open source and by the way, one of the trends that someone actually remarked to me at this FOSDEM and I think it's a trend over the last few FOSDEMs is that there are more and more, I could possibly qualify them as non-technical dev rooms, as you say, policy, community, sustainability and things more around and about open source rather than technical development the things which I think is good. mean, it's but it's it's a trend and I think that also connects to policy, EU policy and open source in society and the greater scheme of things. So yeah, I am involved with a little bit of that and going back to what you talked about the open source academy, I also participated in ⁓ the EU Open Source Policy Summit on the Friday before FOSDEM and that's really one of those EU policy things. Lots of people with ties. 00:07:56.000 --> 00:08:05.000 And do you feel that you attending it like makes a difference? I mean, is it just ceremony or do you actually do something also pragmatic there? 00:08:05.000 --> 00:09:06.000 In that particular one, I participated in a panel discussion. So I like to think that I actually contribute something. you know, I try and I do believe in that there is, I mean, that we have almost an obligation or at least some kind of benefit to impact and help the discussion when it comes to policy and, politicians and EU in general, right? We have to sort of help them understand what open source is about and if we ever want their help, right? So it's good to have those kind of bridges and cooperation opportunities, even if it feels sometimes a little bit strange to participate in that kind of a crowd when you feel like an open source. developer, I'd rather just write code, right? I don't want to talk about EU policies, but okay, sometimes I make an effort to anyway. 00:09:06.000 --> 00:09:57.000 Yeah. And again, as you are definitely not just any open source contributor, you have quite a lot of say, I would say. think people listen to you. They respect you. So I think that is definitely something you can use for the good, which you seem to be doing very well. And I would think that the fact that we get these non-coding initiatives at Fossdem it does kind of mean that open source is kind of getting more, I don't know, accepted or being given spotlight in policies and giving the stage it deserves. and maybe even becoming, I would one day hope it becomes even mandatory for things like anything that governments would order to build when they build software that is open source, that they build foundation open source. So mean maybe I'm just naive but I would hope that this is like showing that we are getting a direction. I'm sure what you think about that. 00:09:57.000 --> 00:10:53.000 I agree. It's ⁓ growing up slowly. and you're right. And I think open source is being used possibly more than ever in virtually everything. So I think it's only fair that we're starting to also talk about it as the, as a really found them sort of the way to do development for a lot of foundational. software components in our infrastructure really. And it is good that everyone realizes that and starts to act on that and make sure that open source continues to not only survive, but also to strive and remain sustainable. Because the society and lots of our daily life is built upon open source nowadays. 00:10:53.000 --> 00:11:04.000 Yeah, for sure. And then since 2023, if I'm correct, you're also a member of the Polham Council. Are you still a member of that? 00:11:04.000 --> 00:11:49.000 Yes, I am. So I got that award which is a Swedish engineering award which they like to say is older than the Nobel Prize and it is I think it celebrates 150 years in next year or so. So it's a really old engineering award in Sweden and I was awarded that in 2017. I got an excellent gold medal. then after a few years I was asked to participate in the council who help out to award other awardees in the years to come. It's actually, I would say an honor and a pleasure to do that. So I think that's really awesome. 00:11:49.000 --> 00:12:04.000 Okay, does that mean that in Sweden it's less controversy to call software development engineering? Because I know in some countries you're not even allowed to say that and there's like a lot of discussion often around it. I'm not sure what you think about that. 00:12:04.000 --> 00:13:04.000 I don't think there's lots of discussion about it. I think sometimes it's just being overlooked or ignored, in particular open source of course. ⁓ That's one of the upsides I think with me getting the award, both for software in general, but also for open source to help highlight to the world that it's actually a pretty important part of engineering and of society and everything. So yeah, for the Pohlham Prize then, so I was the first software person to get the award, right? So 140 years or so into its life. But now we have awarded several other software engineers since then. And I think in general, in Sweden at least is certainly accepted as an engineering. I see a lot of software people getting awarded for different kind of engineering circles. 00:13:04.000 --> 00:13:28.000 Okay, I mean that's nice to hear and anyway maybe it's a bit of a silly discussion anyway. Is there like a lot of similarities then between what the Pohlheim Council does and the European Open Source Academy? I mean of course the focus is different but let's say that because I guess in the European Open Source Academy it's about open source but despite that is it just about our words or is it more than that? 00:13:28.000 --> 00:15:42.000 The ambition is slightly higher, but I think it starts with the awards and making sure that we keep highlighting and ⁓ celebrating the excellent open source people, contributors, maintainers that we have in Europe. ⁓ And it goes back a little bit to the policy debate or discussion that it is important for it is important for ⁓ maybe for Europe more than other regions in the world that we keep being excellent at open source. And the term digital sovereignty is often phrased right because if anyone wants to become sovereign or slightly independent, open source is a key component to that. and then when it comes to then celebrating and highlighting excellent open source, it's also about perhaps educating and advocating for open source in general. So the ambition is I think is fairly high. I think the question is probably what we will manage and actually accomplish. But we're starting out with the awards and that's at least for me I think that's the biggest emphasis so far. The challenge with anything you know when you get a team together and you want to have the let's say we are at least among the top open source contributors in Europe, is that everyone is really busy already. We can't just start something and assume that a lot of people will be able to spend a lot of time and energy into a new venue, a new venture like an academy. So we only have whatever time is left from everyone that can participate. So we can't have too high ambitions at the same time because we won't be able to pull that off. We also have to ⁓ to keep maintaining our own open source projects and our own open source whatever we do. But I'm optimistic. I think this is a good venue and a good start and we will just have to work on making the best out of it and see where it goes forward. 00:15:42.000 --> 00:15:51.000 And so how did it get started? And you were also the president. So was it like you were elected or just because you have to get it started or? Yeah. 00:15:51.000 --> 00:17:58.000 That's a very good question. So yes, I am the president of the European Open Source Academy. And the thing is, when you start something, you have to start somewhere, right? So I was not elected, but we're now creating the foundation and the internal governance for how we are, how this should do in the future. So we want to lay the groundwork so that we can do it properly going forward. So I'm just basically the start off. point here and I was actually just asked if I wanted to start and if I could consider taking on this role when we started this and I figured hey why not because I believe in the idea I believe in open source I believe in Europe so and I believe in the idea of awards to open source contributors in in Europe because that's nothing we had before and I certainly want to help highlight and celebrate that. Perhaps also back to the policy thing, perhaps, is that this academy is currently funded by the EU even. So it's an EU project for the moment. Which means that, yeah, it was created by a bunch of people who suggested this to the EU as a thing for us in Europe. And the EU decided it was good enough as an idea to fire off, fire up. So I think we're funded for three years initially and in part of our ⁓ agenda now in the academy then is of course to partly restructure so that we become a legal entity and then partly to make sure that we have funding and ways to survive after they possibly stop funding us from the EU. Maybe they won't stop, maybe they will. ⁓ continue the funding. But anyway, we want to make sure that we have the groundwork set so that we can also accept other ways or means of funding so that the Academy actually survives after 2027, I think. 00:17:58.000 --> 00:18:08.000 Yeah, yeah. And how do you, yeah, how does it operate? Is it like you meet every month online or like, I don't know, like what's your operators to work together? 00:18:08.000 --> 00:19:02.000 Yeah, we have meetings online, we have a mailing list, we have discussions. there's a lot of and also some individual members of the academy are, you know, publishing opinion pieces or writing articles or blogging about things. So there's a little bit of those kinds of activities going on all the time too. We try to respond to EU questions and participate in some different. We want to be helpful to the EU and European Commission and everything when they have things that are related to open source because it feels like we could be that party sometimes to at least help them, help guide them a little bit when it comes to open source, perhaps understand it a little bit better or direct them to the right places where they could educate themselves more. 00:19:02.000 --> 00:19:13.000 Yeah, for sure. And does that mean that you will also try to have some influence over the European Parliament and how they operate and make decisions around open source software? 00:19:13.000 --> 00:20:03.000 I mean, don't we all want to influence them in the right direction? But I'm not sure it'll work. But if we manage to, you know, do all of this that I'm suggesting, then maybe we long term actually influence Europe and the EU to educate them and help everyone understand a little bit more about open source. In that way, we could help everyone really. So yes, in that regard, I think we could influence them, but not I mean, not directly. It's not that we're going to tell them how to do or then they're not going to ask us, should we go left or right here? And we're going to say right or left. But ideally, we help the greater community to understand more and appreciate it more and possibly also help sustain the ecosystem better going forward. 00:20:03.000 --> 00:20:24.000 Very cool. mean, I look forward to seeing how it evolves. It is definitely exciting now. Maybe my last question about it, like, and maybe it's a bit too early to ask, but like, how is it being received by the, like, open source community in general? Like, how was the feedback so far on this creation of this institute? 00:20:24.000 --> 00:20:28.000 I think it's lukewarm so far. But I think also, I think it's fair. I think it's fair to be skeptical and just wait around and see what is this? Is it worth our attention? Is it worth anything? So I think it's fair to not be overly excited because we haven't proven to be useful or worthy of anything yet. ⁓ 00:20:28.000 --> 00:20:52.000 You 00:20:52.000 --> 00:21:25.000 I think cautiously optimistic might be another word. So I think people think it's a good idea in general. I also hope that going forward, we will just make it more accepted and more, I don't know, popular. But what do you do? I think the most important part is that we should just prove ourselves, our worthiness by action and by awarding the right people. And then if we do, hope that people think we're doing the right thing. 00:21:25.000 --> 00:21:54.000 Okay, and of course it helps a lot that they have a heavy hitter like you as a president. I said, I do think you have lot of influence over the, or at least respect in the open source community so people do listen to you. And then other people that I would think of in the European open source community would be, maybe people like Linus Torvald, but I think he's a bit apolitical, so not sure if he's a person that would also want to get involved in something like this. 00:21:54.000 --> 00:22:22.000 Right, but then we come back to the eternal question we have here. We are the European open source academy. What does it mean to be European? We actually have some wording that says it's also for European citizens or people with a tight connection to Europe or whatever. like in Lino Storvalds fall case it might be maybe it's not European enough anymore. 00:22:22.000 --> 00:22:24.000 You ⁓ 00:22:24.000 --> 00:23:19.000 I don't want to specifically highlight him, but still it is about Europe here. Because we also felt that that's the mandate we have. It's a little bit strange to do those kind of borders because I never feel that I work in a European open source project or anything because I don't feel an open source project is limited to a region like that. It's just an open source project. We don't have any borders. participates or not. We don't care. Usually we don't even know where people are from. But still, it's also question of what you feel you have taken on. In this case, we are all Europeans. We feel that we have a mandate to do this for Europe. We don't feel that we have the mandate to do this for the world. So that's why here we are. 00:23:19.000 --> 00:23:57.000 Okay, and so while you might not really feel there are like regional borders, you do put some kind of borders, for example around AI usage, and I know you're not like an AI skeptical, it's not like you're anti AI per se, you see the use of it and you're very pragmatic and balanced as far as I can see in it, so I appreciate that. But then something that caught a lot of wind. in the press recently was the fact that you closed like the Buch bounty project and I understand why but do you feel it it was do you still feel it's the right decision that you you closed it? 00:23:57.000 --> 00:24:15.000 Everything changes day by day. basically just a few days ago, I was like, yes, I could certainly feel that the frequency has gone down. This might have been a successful move. And now today, I'm less sure again, because now, I don't know, it changes day by day. But really, I think it's actually too early to tell. So I think I should just not risk sort of 00:24:15.000 --> 00:24:27.000 You 00:24:27.000 --> 00:25:38.000 be emotional to think about it day by day. I should just let it be and we come back maybe give it two, three months or whatever and then reassess count the frequency and see was it actually a good move or not. So ⁓ let's see it might be good. It might have no effect at all. then the next follow up question is of course, if there is no effect at all by dropping the back bounty, what do we do then? Do we bring it back? Do we keep it like this and just try something else? ⁓ Yeah, but again, I rather not plan that too much, but just hold off for a while and see what happens and suffer a little bit, but we'll see where it goes. Since we're in the world where it's so easy to just send in crappy reports, we need to do something to address the influx, right? sort of make something that makes it that requires the users to do something else or to do something more or something. I don't know really what the answer is. 00:25:38.000 --> 00:26:03.000 Yeah, and I know that for example, some of the good use cases around this technology that you did see is that there are some security firms who do seem to pull off high quality reports in this usage. I would think, would it be a possibility that you also use this technology to maybe as a first filter to filter out these reports or is it like too flaky? Yeah. 00:26:03.000 --> 00:27:20.000 It's too hard. It's too hard. It's too flaky. because the problem isn't, I mean, I could possibly use a tool that would detect AI reasonably well, at least there are, I mean, you could say this is 99 % certain that it is AI. But that would be, I think that would catch the wrong things because it's not AI I want to catch. I want to catch the crappy reports. And detecting crappy reports is not that easy to do automatically. I'm working with some teams that are also stressing that part. So maybe we should have a process that if you report a security problem, you should provide detailed ways on how to reproduce it. And that would be more or less mandatory. because if we can reproduce it with a description, that's and then that's pretty much accurate, right? If you can't reproduce it, that's a signal that maybe it's not real. But we also have a large amount of bugs where basically We can't reproduce it, but it's still a valid bug or potentially a vulnerability. So we can't have that as a strict rule, but maybe we should try to push back harder on reporters to actually provide enough data. I don't know. As long as we don't have that as a mandatory rule, I'm a little bit scared that people will just always take the exception. Well, I couldn't in this case, but I promise it's a genuine bug. 00:27:20.000 --> 00:27:32.000 Yeah. 00:27:32.000 --> 00:27:33.000 And I fear that every AI-generated report will then go that route and then we haven't solved anything. So I don't know. People also keep saying that I should charge for the, you know, the opportunity to submit a vulnerability. That would certainly be one way to limit lots of crap because people wouldn't pay to submit lots of crap. But also if we just charge... 00:27:33.000 --> 00:28:00.000 you 00:28:00.000 --> 00:29:06.000 I mean, a lot of these users, actually think they help. So I suspect that if removing the bug bounty doesn't help, I don't think adding a very low fee will help either. I think we need something else. And then maybe we should have, then people, could have it even more complicated, requiring that the user submits a vulnerability has some kind of credibility. They have done something else in our project or in another project or something, you know, to... get rid of all those new accounts that were created last week and actually are more likely to be abusive or something. Sure, we could do that too. So that's one way to do it. That will then take away all those newcomers who are legitimate newcomers just that they didn't have an account previously. I mean, so there are trades and balances ⁓ with everything. We'll see. First off, we're going to just see where we go. 00:29:06.000 --> 00:29:12.000 It's a tricky problem, course, and I'm not even sure it's a technical problem. And like you mentioned, yeah. 00:29:12.000 --> 00:29:31.000 Exactly. There's an in-between somewhere. And we're certainly not alone with this problem either. We are a whole world now facing this problem in all sorts of different areas. So ideally, we can also see how others go and learn from others' experiences too. 00:29:31.000 --> 00:29:56.000 Yeah, yeah. And I mean, it's not an easy problem. And you mentioned, okay, you asked for them to give you steps to reproduce it, but you also highlighted in your talk at FOSDEM, like a particular example where they basically gave you fake GDP sessions and things that didn't exist. So it would still take you a while, I guess, to figure out, okay, this is not even legitimate. 00:29:56.000 --> 00:30:28.000 Exactly, so you have to also verify that the reproducer actually reproduces. You can't just believe a claim or know read the recipes or the output because they might and not only might they are fake in a lot of cases. So yeah you have to get reproducers enough so that you can actually run it yourself and verify the reproducer then you know for sure that you can reproduce whatever they say is reproducible and then it's the next question is that a vulnerability or just a bug or or documented feature or whatever. 00:30:28.000 --> 00:30:54.000 And of course in an ideal scenario you would say okay you have to give a patch where you actually like trigger some kind of new test case which has it reproduced but of course not everything can be as easily reproduced in the CI despite how like extensive your CI system is like it's there are probably plenty of and especially the more high valuable bugs you probably cannot really reproduce them so 00:30:54.000 --> 00:31:47.000 Yeah, imagine a timing sensitive or you race conditions and everything. I mean, they're perfectly valid bugs, but sometimes really, really hard to reproduce. And I don't want to dismiss a valid, proper security problem just because the reporter can't reproduce it. That's also ⁓ sometimes even for an experienced current developer, it's sometimes hard to write a test case for a particular set of sequences, right? So depending on what it is and It seems weird to put that as a hard requirement on a reporter. Sure, we want them to try and it's really awesome if we could go there, but I don't think we can have it as a mandatory requirement. And if we can't have it as a mandatory requirement, people are going to use the sort of the escape patch and say, hey, I can't use it. just read it anyway. And then we're back to square one pretty much. 00:31:47.000 --> 00:31:57.000 Hmm and and how is it with your legitimate books? Did they increase or decrease or are they pretty much flat or? 00:31:57.000 --> 00:32:35.000 I think it's pretty much flat. That's hard to say. I mean it depends on how you count. Since over time we also have more code so depending on which curve you're looking at we have less CVEs per number of lines of code over time. But basically I think we have more or less stable number of CVEs per year through the last five years or so, around I would say 10 maybe, a little bit more than 10 perhaps. 00:32:35.000 --> 00:33:01.000 Okay. And you also mentioned that you did have some, like, it's not as simple because there's, you have at one end the really good use of technology and another end the really bad use. And so you highlighted that you do appreciate or maybe I'm misinterpreting your words, the good use. Is that something you actually actively use or it's more these companies come to you and they submit these reports and you do accept these? 00:33:01.000 --> 00:34:53.000 Both actually. So I've had, I have several teams using AI powered tools that are running scans on curl and they do sort of the triaging, analyzing, assessing, and then they say, look at this, don't you think this is a security problem or at least a bug? And then we work together. Is it a problem? Is it a bug? Is it nothing? And then they sort of become an extended dev team. we work together to figure out what they found and what to do about it. And in several of those cases, yes, we conclude that yes, this is a security problem and then it becomes a CV in the end. So that's really the best way we've seen AI powered tools in use. And I think some of Also of the valid security reports we have, I mean, not as a cooperation or anything, someone just shows up one day and submit a security report. Some of them are also obviously done with the help of AI, but ending up with a legitimate security problem and everything is great. And it's just that, they use some kind of AI powered tool to find it and often to write the report, but that's good, right? When the report is accurate, it's actually vulnerability. It helps us. helps the... ecosystem and everyone when we fix this problem. So in that case it's awesome. So it's really an augmenting tool, right? It can augment you to go in the wrong direction or in the right direction. You need a person with a brain to understand and filter out the bad stuff and cherry pick the good stuff and bring the good stuff to us and then it's really good, potentially sometimes. 00:34:53.000 --> 00:35:02.000 And so that's the key difference you think is like if you have an expert and they use it and they use it properly, that's the key difference here. 00:35:02.000 --> 00:36:48.000 I think that's a key difference. There might be others too. think for example, most of them that have actually used AI to find security problems in curl, they haven't just asked the AI bot for this and just went with whatever it said. They have used more specialized tools or done repeated questions, filtering out stuff or ask about specific things or reiterated into some specific area. So yes. I think the key is also that these people that actually report something good, they have actually also understood the problem, possibly even tried to reproduce it manually after the AI told them about it. So they actually did that extra piece of work that people have always done when they did security reporting. You find something, you suspect something, you dig around, you research, you try, you reproduce, and then you submit the report. The really bad stuff happens when you skip a bunch of those steps and you think that you can just ask the AI and submit. And if you do that, you're likely to just submit crap because the AI is as many other. I mean, that's not unique for AI really, because any code analyzer on any code will... often report a lot of false positives because of just code isn't always straightforward and there's a matter of api's opinions layers so what's right what's wrong what's the problem what's okay you need you need the you usually need a person to guide the tool 00:36:48.000 --> 00:37:01.000 And then now so far we've seen how the good can come to you via external contributors. Can you give them examples of how you're using it yourself as well? 00:37:01.000 --> 00:40:32.000 Yeah, so for example, I have an account on one of these AI powered tool Zero Path. So I actually, since a few months back, keep running repeated scans using that tool on the curl code. It's just like running a code analyzer. It is a code analyzer, really. we run, I mean, we have a lot of code analyzers that we run on the curl code repeatedly in CI and just ⁓ sort of on a schedule and this is just another code analyzer that we're running on the code repeatedly and it finds things that the other code analyzers don't find. And recently I also like to throw some AI review bots on my PRs. have some of those that just helped me point out some mistakes in my pull requests, which is also. helpful. It feels like some automatic team members you can ask for some feedback on your pull request and it'll find something maybe. Often remark on stupid things like hey you changed the logic but you didn't change the log output. You're saying you forgot to update the comment when you changed the logic or you have the same pattern in another function so why don't you update that as well. because now it seems one of them must be wrong or things like that, just helpful things. of course, even though they are also wrong at times because AIs are and code analyzers too, right? even, mean, compilers are sometimes wrong when they warn about something, right? And then you just, either you accept that, okay, I update and fix it, or you make it shut up and say, no, I'm right, you're wrong and I move on. I think for code reviews, it's really a mental state that we're used to, right? If I ask a human for a review, he might have three comments on my patch, right? And that's all fine. But one of the comments I might not agree with, think that person thinks I should do blah, blah, blah instead of the way I did it. But I think he's wrong or right. Or she says something that and I can just, you know, it's a more of a... conversation or back and forth rather than dictating truths. So in that way, it feels like, okay, when the AI review bot says something wrong, it feels like just a human that had the wrong suggestion. Nope, I don't want to do that. Go away. But the other suggestion might be perfectly fine. thanks to, ⁓ I mean, improving the PR with an AI actually then helps. It reduces the load on the humans and then because after I have then perfected my patch with AI, it's never perfect anyway, right? But I could at least fix a few flaws that it pointed out. And then if I ask a user for feedback on my PR, they don't have to remark on those low hanging fruit that the AI bots found. So I think it's helpful, I think. I think I can write better code or I can land code that is slightly more mature ⁓ than I do without them. 00:40:32.000 --> 00:40:59.000 and I would have asked you okay like one thing is these things catch it and then maybe hopefully a second thing would be you can analyze how that slipped in to begin with and you can maybe find a better way to automatically test it but the examples you highlighted seemed very difficult to to test of course because they all seem to be not something that our current tooling is really dealing with 00:40:59.000 --> 00:42:32.000 No, exactly. that's also how these tools differ from the standard tools. They view and read the code in a, I shouldn't say this, but they're more human-like that they work on the text and not on the code, which is sometimes good, sometimes bad. you know, for example, when the comment is not the same as the code, no previous code analyzer did that because they work on the they don't really care about the comments. They could care about the comments, you know, formatting wise or stuff like that. so I think that's why this is helpful. It looks at the code from a different angle than a lot of other things. And of course, that, I mean, this is in addition to everything else, right? So we already run all the other code analyzers. And I think it's super important these days to have a really good test suite that makes sure that everything we throw at it keeps working, right? And that's key, I think also to making sure that it doesn't matter too much if someone writes a PR with the help of AI, as long as all the existing test cases run green, we know that at least everything existing keeps working. So that helps also helps us sort of ⁓ combat or be more the amount of AI crap in pull requests. It's not a problem for us, I think, partly because of that. 00:42:32.000 --> 00:42:48.000 And so, so far, as far as I understand the use case you mentioned, they're all ⁓ LLM technology running outside your computer. Is it all something you run on your own computer or there's no need for that? 00:42:48.000 --> 00:42:55.000 I don't do that, but I mean, users do. 00:42:55.000 --> 00:43:00.000 Okay, so have you tried it as well or was just like not even interested? 00:43:00.000 --> 00:44:11.000 I have tried a little bit. It doesn't fit well into my workflow, I think. I haven't been very impressed by it. Most of everything I do code-wise is tweaking existing curl code. I haven't found the AIs to be very... Maybe not very good. Basically, it's complicated to use it in a way that's a lot of my coding is sort of things, my fingers and pretty much it's just in my backbone. I know exactly what I want to do. sit, I want to use my editor. I want to use my key presses. I know exactly what I want to do, but that doesn't go well. I don't can't interact with AIs too. So I have to pick either or do I want to go the AI way or do I want to go about it my regular ⁓ common way? my habits from 30, 40 years. So then I often go with my habit way because I feel that's where I'm at home. That's how I'm comfortable. And that's how I am generally most productive. 00:44:11.000 --> 00:44:23.000 And do you also feel that it's also because what you do you don't think is something that it could do for you? Like it wouldn't even work even if you would like it? Or is it more just about preference? 00:44:23.000 --> 00:45:41.000 I know it can work and especially if you are selective with picking pieces. So for example, can most certainly just, if you fire up the curl code in one of those AI editors or something, can certainly make it rewrite a function or improve a function. And I've done that, I've tried that. And it's fun to, if you have a tight loop, you want to run as fast as possible, ask the AI to rewrite it in a way that it thinks is faster. Which is kind of interesting because the LLM doesn't actually know what is faster. But it's still fun and you can still get it. It's like throwing out the task on an eager junior. It will give you back an answer and say, here, this is faster. Maybe it is, maybe it's not. And maybe it can introduce, ⁓ it may do a fun solution on line three to five. And that's a solution I could use. And then you cherry pick that solution. Good idea. We should use that. part. The rest of it maybe wasn't that nice, but we can use that thing. So I think it's still a, you can use it as a bouncing ideas with it and generating new ways of doing things and see. And yeah, and on and off, you get a really good idea and then you can do that. Sometimes you get really bad idea and you should avoid that. 00:45:41.000 --> 00:46:02.000 Yeah, yeah. I mean, that's also my experience so far. Another experience so far is that it gaslights you a lot. Like it is very confident in some kind of approach and you keep saying, no, this doesn't work for X and Y and you like just in the loop and it just somehow it is too confident. It doesn't even like can go away from its position. 00:46:02.000 --> 00:47:28.000 Yep, yeah yeah so and it has a lot of assumptions so if you if you don't specify it clearly it will assume a lot of things. For example in my case I write C code and I write the oldest possible not the oldest but C89 which is a very old flavor at least of C and that is for example if I just ask it to generate C code it won't use C89 so it will use a more modern version of C so I have to do no no it needs to be C89 And then it easily generates code that is, for example, if you ask it to optimize a loop, it might very well optimize it in ways that is either 64 bit special, you know, it requires a 64 bit architecture, or it requires a little ndn CPU and things like that. It'll just assume because that's what a lot of code does that it has been trained on. it's easily, you easily get tiny mistakes in there. And as you say, it's very confident. Here's a much better way to do it. says on here that you get it. And again, it comes up to this. You get the most out of this by being a clever human and using and use this as a tool and understand when the answers are good and when they're bad. And then you can get the most of it out of it and don't assume that you always get the right things. 00:47:28.000 --> 00:47:46.000 And how do you see this? I mean, it's a bit of dangerous question because I'm kind of like going to ask you how to the future, but like at least in the near term, how do you see this evolving and how might it impact how you do your work at Curl? 00:47:46.000 --> 00:49:24.000 Short term, think we're just going to see more of all of this and we're certainly going to see more tools because I think it's an area where everyone wants to make money. So I think we're going to see more and more tools that regular, I mean, as everyone puts in AI into everything these days, we're certainly going to make, we're going to see that in all sorts of tooling. And then of course we're going to see some upsides because the more tools we get, the more people are going to work on this, the better some of them are going to be. So we're going to be able to fix mistakes better than ever before, find mistakes better. And that should ideally make things more solid and work even better. But at the same time, there's this overall challenge that Maybe if everyone starts to generate a lot of code on their own, know, the vibe coding style of everything. If you do that to a very large degree, that would potentially, you know, lower the value of open source in general, because you would always just generate your own crap and not use the open source components everywhere. I think, however, that is a little bit of a far fetched future because I think... Most of what everyone calls vibe coding is just the leaves of the tree. It's much harder and the leaves are using components underneath anyway. And those components someone has to do and maintain and sustain. 00:49:24.000 --> 00:49:42.000 Yes and yeah ⁓ a lot okay so so there are these old stories about oracles and and some kind of king might ask a question to an oracle and might get an answer but it might have been just the wrong question and so the reason why I bring it up is like 00:49:42.000 --> 00:49:46.000 Yeah. 00:49:46.000 --> 00:50:36.000 So you also maintain a large code base, so I'm wondering how similar it for you, but I also maintain a large code base and I'm so often going through the code, not because I'm just reading at random, but because I'm changing something here and it reminds me of this. And it's often because I'm reading these parts and even if I'm doing a refactor, I could sometimes do something much more quicker with something like grep, but I still choose to do parts manually because I know I will have to think really carefully about each line, which makes me realize something. that I otherwise wouldn't realize and I feel I mean all of that is lost right because yeah the thing you asked for you asked a question to the Oracle it gives you an answer the answer is satisfying enough but you you kind of miss all the questions that you didn't ask on the way is that something you you can relate to or 00:50:36.000 --> 00:52:18.000 Yes, yeah and I think that's also part of the reason why it's why humans are still vital and key to making everything like this work. So the regular mantra of the last few years that we should get rid of developers and you know let the AIs run and everything is not going to work and it's I mean it's not even close to working right so it's just a weird idea. So, but okay, I can't foresee the future. I don't know, but that's how what it feels like to me, at least for the moment. And I feel like I'm getting AIs from all sorts of different angles. And sure, it can help you, but it's not going to take away the humans. And I don't see it replacing a lot of components in the software infrastructure short term either. It feels like mostly it's going to add up. It's going to add a lot of source code to the big pile of code we already have. We have over the last decades added so much source code. So the world has so much source code. We add source code in a much higher speed than we add developers. So the average number of code lines per developer has been increasing a lot over the years. And adding AI here that are just producing code at an immense speed is just going to add to this. yeah, so hopefully, I mean, of course, the AI is then also help us manage that code mass, but still, it's going to be a crazy world. 00:52:18.000 --> 00:52:22.000 But do they? mean, is it not just gonna like collect depth on on depth on depth because I don't, yeah, I mean, I don't feel writing code was ever the challenge here. It's about knowing when not to write code or when to step back and abstract differently. 00:52:22.000 --> 00:53:08.000 Yes, yeah, I think so. Exactly, that's a really good point. Or as a friend of mine said, writing the code once, that's the easy part. I mean, sure do that with an AI, but that's never the problem to write the code the first time, right? Everyone can write the code the first time. It's maintaining it and making sure that it works and it has the same API in a stable way for 20 years. That's the challenge. So, and we don't see... I mean, and do that with our humans. That's going to be, I don't think that's, we're not at that point now anyway. 00:53:08.000 --> 00:54:32.000 Yeah, no, and I feel and... So for example, I'm now into software and I've been doing it for close to two decades. But I feel it just because I'm living in this kind of time where that kind of mindset where you like to do problem solving, where you like to think about these things is very applicable to software. would feel if I live in a different area, I would do something different and I would apply that kind of skills in a different way. And maybe I'm wrong here, but I feel if there would ever be really truly a technology and I would be very different from LLMs because I don't think that will ever get you there but which can really produce like let's say it could really produce something like like curl overnight from scratch like really from scratch not using components but it could really write those things it could make the proper abstractions I would feel at that point it could do literally anything because to me it feels like coding is is basically the art of abstractions and and and making connections and relations and I feel I feel that's pretty much what humanity is about. We obstruct, we make connections, we make leaps of jumps and we apply them and aggregate that knowledge over time. And if it could do that, then what still, I mean, that would just replace anything, not just software. I mean, I would imagine you can just do anything at that point. Maybe I'm giving too much value to software, but that's kind of been my view on it so far. 00:54:32.000 --> 00:55:06.000 No, you're of course right. If, but that's a really big if. And it's not like, I mean, and that's going back to asking the right question. You'd have to ask a very specific question to make it do that. So, and asking that question would take a rather good human to do that. Because If you're not asking the right question, that's not the result you're going to get. That's not the answer you're going to get. 00:55:06.000 --> 00:55:16.000 yeah for sure and so okay so so far it's mostly let's wait how it evolves you could have a choice, you just like to lock it up and throw it in the ocean? 00:55:16.000 --> 00:55:38.000 Probably. It was pretty good as it was before this, think. that's not how the world works. We can't pick and choose from what happens in the world. This is just the new reality. And then we deal with it and we adopt it. We work with it or work around it. But yeah. 00:55:38.000 --> 00:55:59.000 Yeah, Well, yeah, it's just so weird and in many ways, but that goes way out of scope of this podcast theme. So I want to slightly switch gears a bit and then start to round off. is there there something ⁓ you want to tell more about about this topic in particular or you think we said enough about it? 00:55:59.000 --> 00:56:02.000 I think we covered it pretty well. 00:56:02.000 --> 00:56:43.000 Yeah, okay. So I guess we will see in some years how we stand by then. And yeah, ⁓ so one thing I'm amazed at with your development, that curl is how time over time and month after month, you keep coming with genuine improvements and things that you might think like, ⁓ curl couldn't do that yet. It seemed like so like an obvious feature that someone might want. For example, recently you or maybe some of your contributors, I'm not sure who is responsible for these, is like you introduced the J option in curl ⁓ to make it have a better name to download as far as I understand. 00:56:43.000 --> 00:56:49.000 Yeah, well the option actually already existed, we just improved how it works. 00:56:49.000 --> 00:56:56.000 And how come then these things after so many years come to service? It's just someone asking for it. 00:56:56.000 --> 01:00:30.000 Yes and it's like everything so it is fascinating but when it comes to something like curl you know we have so many options I think 273 command line options or something so it's it's a ridiculous amount but almost all of them have I mean could be improved in slight ways right because none of them are actually well some of them might be close to perfect but most of them are actually you know they have their tiny flaws and sometimes people say hey I use this option and this happened and yeah yeah yeah we know that that's because blah blah blah and we didn't really think about that when we made it or or someone and so there are there's always in almost every aspect of of a code base like that there is room to improve Which is, I think it's a fascinating topic in itself that you can work on something for so long and keep on iterating and iterating and iterating and it never ever gets done. There's always room to work a little bit extra, do a little bit more on this. And in this particular case, the dash j option, someone actually brought it up to me a month or two ago when they compared curl with another tool and said, hey, with this other tool, I get a name with this, with curl, don't. Why is that? And then I explained. Well, it depends on this. When I implemented this, didn't really go, blah, blah, And then when I had explained that, I thought about it a little bit more and thought, hey, maybe I should take that extra step this time and actually not just wait for and say, hey, that's a known limitation and be done with that. And just could maybe take a look and see if I could fix that limitation because maybe it's time now. Maybe it's... the time is ripe. sometimes, you know, I think part of the reason is sometimes you do something and you end up in a difficult position, you know, doing it all the way, doing 100 % is slightly complicated because the last 3 % of this would require that we would have an entire new thing over there for us to get that information. And we don't have that entire thing. So going all the way is a little bit complicated. So we just were happy with the 97 % solution. And that's what we ship and use. But then over time, maybe we have implemented that other complicated machinery. And then when you come back, and I thought it was like that in this case, and when I revisited this problem now in 2020, well, a few months ago, then I realized we have the whole machinery in there already. It would actually be really easy to do that last 3%. So that last 3 % was really complicated back in 2010, but now we had so much else. also already done so I could do that extra three percent actually quite surprisingly easy so it works a little bit like that right so we're moving pieces all the time so when we come back and revisit design choices from the past where limitations or sometimes even pure bugs they happen because other areas were immature or incomplete so We're moving things everywhere so the more we improve things in one place we can improve things in another place and then we keep on iterating finding new places and all of a sudden we refactor something and then things change and yeah it never it really never ends. 01:00:30.000 --> 01:00:56.000 Yeah, I mean I can relate and for those kind of things I like to also track them because I don't like to put imperfections under the carpet but I know as you say like sometimes it takes a bigger piece of machinery that you would need to make first or a big refactor for which you have no time or desire now but I do at least want to track these. Is it also something that you then also track or is like more like a private backlog in your notebook or something? 01:00:56.000 --> 01:02:12.000 We actually try to document that we have a to-do list and we have a known bugs list that have a bunch of things like this. Sort of unfortunate realities that no one has actually just, you know, we know this is an issue, we should fix it, but no one is around who wants to fix it. No one has the energy. And then we just make sure that we document it here somewhere so that we can, when people bring it up, we can just mention, yeah, we have it mentioned. feel free to work on it, we want to fix it, no one has done it yet. And then, you know, over time, maybe one of us do it, or maybe it just remains in the list. But you're right, I don't wanna hide it either, but I also make sure that when I, for example, this dash j function, I document it clearly, this is how it works, right? And I don't have to say what it doesn't do, I make sure that I clearly document what it does do, and then that implies what it doesn't. and then over time we can then add, now it does this as well to make it even better and then we document that so that we always make sure that users who are using this at least have a chance to understand exactly what it does and how it works. Well, to enough degree anyway. 01:02:12.000 --> 01:02:44.000 And then. What I like to do with these kind of issues as well is like I track them and I also mark them then as like mentor available. So we provide mentorship and I often see then students who are still in university or people who are trying to learn Rus, they pick these up because they appreciate the mentorship. Is that something Curl offers? Like could, let's say I'm really into wanting to learn C or I want to like get more into networking or these kind of issues available for mentorship or how it works. 01:02:44.000 --> 01:04:25.000 Yes, we don't have that as sort of expressed in the issues or pull requests. But we, yeah, maybe we should, but we certainly help everyone to whatever degree they feel ⁓ is necessary or wanted. I mean, I would be happy to see a newcomer take on something like this. I think one of the challenges with curl is that First, we're using C, which is a language that has fallen into oblivion. People don't actually learn it anymore in universities. We're getting a shrinking amount of people who can and want to participate. And then the second, we've fixed most of the low-hanging fruit issues. It's not that easy to just find a silly little bug and fix it and get your feet wet that way. most of these things that are mentioned in these documents are fairly complicated. It's not that easy to just put this together. I mean, either the protocol is challenging or the technical task is challenging or the curl source code infrastructure and architecture could be challenging. So there's a lot of pieces that you actually have to get together in order to be able to put that first. And I think that's what's most scary to people. That's what makes newcomers sometimes not even try to because the existing or the imaginary challenges of the task. 01:04:25.000 --> 01:05:33.000 Okay, fair enough. And then the other question I had about this, something like an improvement to the J flag as an example is, for example, in FOSDEM, there was a talk around rewriting the core utils in Rust. And in general, it goes fine because it tried to be like ⁓ compatible, so to not break anybody. But then you do come into weird edge cases where somebody was relying on the fact that, or for some reason, someone had a file with I don't know like a million characters and it broke their system in this new thing which is of course very weird because who has a line of a million characters but okay that person had that and they complain of course because it's the internet but then I would think that for sure there were there were people who as you gave an example in your blog post where your file is download and they probably have a shell script where they hard-coded I expect this to be download and I move the file as fun. JPEG? Is that something you consider or are just like sorry the previous thing was just wrong and you will have to fix your script? 01:05:33.000 --> 01:07:41.000 I always consider the, I mean, think having a stable functionality is very important to us. So not breaking users scripts is really, really important. So we work really hard on that. I mean, the same curl command line that worked back in 2006 still works exactly like that today. I think very few other command line tools can boast about that. And really all the URLs have broken. probably since then, but curl can still work exactly the same. So we work really hard on that. But when it comes to the dash J option, actually, sort of, could do this change because the dash J option depends on what the server provides you with. That means that as a user, you can't blindly assume that whatever you get back is the same as next time because you don't know. because the server will give you a name at runtime. So in that case, everyone who uses this option would either after the download check what kind of name did it actually give me this time and check in the directory where you download it or curl has an option that can have it tell you the file name that it actually used when it saved. And either way, you can do it either way, it still works exactly like that even with this new modification. So I'm pretty sure that with this minor change, I don't break any use cases. At least use cases that don't assume things that they shouldn't assume, which doesn't, of course, there's going to be a few of those use cases. But I think in those cases, the users will learn that they relied on something they shouldn't rely on because that's... border to dangerous could even be a security related problem if they actually think that whatever the server tells you is going to be the same name every time because you don't know that. ⁓ 01:07:41.000 --> 01:08:06.000 Okay, and then you also recently had like ⁓ a blog post around the transfer protocols you support in Curl. And for the most part, I knew these protocols, but there were some that I didn't know yet. And for example, I know that, I mean, I get FTP and SFTP, but then there was also like a TFTP. What is that about? 01:08:06.000 --> 01:08:35.000 TFTP is the Trivial File Transfer Protocol. It's an ancient thing, but we supported that for 25 years or so. ⁓ It's a UDP-based thing, usually used for bootloaders and trivial use cases. I mean, usually not across the internet, usually from local machines because it's really trivial. It sends blocks of data over a UDP. 01:08:35.000 --> 01:08:39.000 and it's drivable because it's very naive so it's very inefficient. That's what you mean. 01:08:39.000 --> 01:09:17.000 I think it's trivial to implement or I think that's at least what they thought when they made it and I think it is in comparison to a lot of other things because you can do I think that's why it's meant for things like bootloaders where you don't necessarily at least traditionally back in the days you didn't have TCP and everything because TCP is kind of complicated it's easier to implement UDP because it's doesn't do resense and everything so That's why it was easier to implement some. If you want to download your boot image over the network, you did it with UDP. 01:09:17.000 --> 01:09:22.000 Okay and then things like the file protocol is still even used a lot. 01:09:22.000 --> 01:09:34.000 It is used quite a lot, which might be a little bit surprising because it asks the question why, right? If you can read a file, maybe you should just read the file instead of you asking Curl to read the file. Because yeah, you run it locally, you can read the file yourself. But apparently in many cases people tend, when they already have, you know, they build an app that is... 01:09:34.000 --> 01:09:48.000 Exactly. 01:09:48.000 --> 01:10:09.000 built around URLs somehow and they want to get data. So sometimes it's just easier for the applications to, we can get the data from HTTP from blah, blah and pile, colon, blah, blah, blah. So it's just makes it easier integration. They can put everything into one place and Carl does all the transfer, fetching all those things, even when it's from file. 01:10:09.000 --> 01:10:15.000 Okay, and then another one I didn't know about was RTMP. Like what is that about? 01:10:15.000 --> 01:10:20.000 RTMP, that's one we're going to remove later this year, by the way. ⁓ So it's the real-time multimedia protocol, I think it's called. It's one of those ancient things back in the days of Flash and streaming media, how we did things like in the early 2000s. ⁓ Very rarely used these days, often used with just proprietary streaming services from the past. 01:10:20.000 --> 01:10:45.000 Okay. 01:10:45.000 --> 01:11:36.000 No and users are not using that to any particular degree. There are several reasons actually why we have deemed that it's not a good idea to actually keep that support around. So that's going away. to do RTMP transfers we're using a third-party library so it's actually very little code in curl involved in RTMP. it's also doesn't it won't save us a lot of code but it's also one of those things in when you realize after after time it's it's not tested well not by us not by this third-party library it's just a weak area and then when you realize that basically no one uses it we should just work on removing it 01:11:36.000 --> 01:11:44.000 And then the last one on the list I didn't know about was Dict, or D-I-C-T, I'm not sure how you pronounce it. 01:11:44.000 --> 01:11:53.000 Yeah, that's one of those weird ones. We had a support for that really early on and I think that was a mistake but still we keep it there because we added it once, we keep it there. No one uses it, we don't have to touch it. there are like, I mean, how do we know if anyone ever uses anything, right? We don't have any telemetries or counters or anything, we don't know but every year we have a survey, we try to get as many people as possible to... 01:11:53.000 --> 01:12:13.000 you 01:12:13.000 --> 01:12:57.000 answer to and then we ask which protocols are you using with curl which is a weak way to figure out because i mean people can lie right and we only get like a thousand responses and we have far more users than 1000 but anyway then we know that x percent of users are using pretty much i mean we know then that all protocols are used by users at least they claim so even rtmp that we're going to remove. there are users. The question is just how many are they? So we know that users are using dict and dict is a dictionary lookup protocol. Basically ask a server the definition for a word and you get it back in a structured way. I mean nowadays you go to Wikipedia or something and check it there but they once made a protocol for this and this is again I think they made it in the late 90s or something. 01:12:57.000 --> 01:13:09.000 Okay, that's... 01:13:09.000 --> 01:13:19.000 Back in the days when we still thought that we would use a lot of different protocols for a lot of different things before we really transitioned into doing everything over HTTP. 01:13:19.000 --> 01:13:24.000 I mean, anyway, it seems a bit too niche to make for everything a different protocol. Okay. And so do you publish these survey results? Like, can I see like, what is the top protocols being used? 01:13:24.000 --> 01:13:41.000 Yeah, I agree. Yes, you can. They're available somewhere on the website. 01:13:41.000 --> 01:13:44.000 Well, you have so much information. 01:13:44.000 --> 01:13:48.000 Yeah, too many, too much. ⁓ But yeah. 01:13:48.000 --> 01:13:51.000 Maybe you should have your own LLM there or something that you can ask questions to. 01:13:51.000 --> 01:13:59.000 Too much documentation. So right now I don't know exactly where. But yeah, somewhere on the site we have a survey collection. And yes, we put up a survey analysis every year so you can see the distribution which protocols are used by how many users. And of course, mean, HTTP and HBS are always the by far most popular protocols. 01:13:59.000 --> 01:14:23.000 You Okay, yeah. Yeah, I mean, HTTP is basically leading the world, so I can understand. And so we, you mentioned, okay, first we don't really know how to, which protocols are being used, but we do have the survey. And from the survey, you gather that RTMP is not used a lot, but it is used a bit. 01:14:23.000 --> 01:15:17.000 Yes, exactly. Yeah, it's also the combination with the other bad things around it. So it's mostly like the lack of testing and asking around. Hello, is anyone using it? And no one says yes. And we ask that question a lot and we say, hey, we're going to remove it. Please shout loudly if that's going to hurt you. No one says anything. And when we do this for a while, And so it's more of that combination, that sequence of different things that makes us take that. eventual call that, hey, then we rip it out. I'm sure that someone will down the line come back and say, hey, what happened to my RTMP? And they will be very mad. And this might happen in, know, 45, seven, 12 years down the line. I'm sure it's going to happen. But at the same time, we have to make some of those hard choices sometimes just for the greater good of the project. And yeah, just move on. We also have to... 01:15:17.000 --> 01:15:37.000 Yeah. 01:15:37.000 --> 01:15:53.000 Take the entire thing into consideration. What's good move here for the project? Is it good or is it bad to keep it? It's not easy to make the decisions either. We have to just make some judgment calls. 01:15:53.000 --> 01:16:08.000 And would there be a way to move that kind of code to a separate repository which you archive and you say with this kind of custom build command you can just include it, but we don't maintain it, we don't take responsibility for it. 01:16:08.000 --> 01:16:54.000 Well, the shorter answer to that would be no. Because I mean, if they want it, they can go back in history to the particular commit where we removed it. And there it is. But maintaining it and make sure that it keeps working with later versions, that's going to be a lot of work. I mean, part of the reason why we remove it is that we don't want that work, right? Because if we want to keep support for it, then we would keep it. So no, when we we cut it out, we cut it out, then it's up to someone else to if they want to bring it back. they need to do that in an external patch which at least short term should be really easy but over time might need more and more work of course like anything patch ⁓ that is outside the project's git tree. 01:16:54.000 --> 01:16:59.000 that happen a lot that you over the years remove a lot of these protocols or is rare 01:16:59.000 --> 01:17:53.000 We have not removed a protocol really ever. We actually did it once, but we brought it back, Gopher, but that was like, I think 20 years ago. otherwise we remove things, we do quite a lot of things, but usually we remove support for like a third-party library. And then we support others instead. So that means that we can still maintain the API and ABI and everything. just have to... the users just have to build it differently. Sometimes we drop support for a particular option in curl. But we only do that in ways so that we maintain backwards compatibility so that applications and users can still do things exactly the way they did before. 01:17:53.000 --> 01:18:05.000 Well, with that I think we can wrap it up. Is there something you want to promote or shout out or still mention before we say our goodbyes? 01:18:05.000 --> 01:18:09.000 I don't think so. We covered a lot of ground here today. I think we covered most of it. 01:18:09.000 --> 01:18:40.000 yeah okay very cool well i appreciate you taking the time to join the podcast it's the second time you first appeared in episode six where we talked more about the origins of curl and how it evolved and now I'm glad that we were able to focus a bit on the present and the issues you're dealing with now and how it's going. And I'm very glad to see that it's all going pretty well for you except for the other little storm, but it seems you're weathering it. 01:18:40.000 --> 01:18:46.000 Yeah, there are some hiccups, yeah, in the graded scheme of things, it's all fine. 01:18:46.000 --> 01:18:52.000 Yeah, well, I wish you the best of luck with it and strength and I will see you around. 01:18:52.000 --> 01:18:55.000 Absolutely, thank you. 01:18:55.000 --> 01:19:00.000 Netstack.fm is brought to you by Plabayo building secure, open, and resilient infrastructure with Rust protocols, and purpose. This show is also made possible by Rama, the open source networking framework. Plabayo offers service contracts and welcome sponsorships to keep building and supporting its ecosystem. The theme music of this podcast was composed by DJ Mailbox. If you enjoyed this episode, don't forget to subscribe on your favorite podcast platform and leave a five-star review. It really helps others discover the show. Thanks for tuning in. We'll see you next time for the next handshake.