Tech Over Tea - The Future Of Linux Core Utils Is Rust | Sylvestre Ledru

Episode Date: August 28, 2026

Today we have the developer of the Rust Coreutils Uutils on the show to talk about the state of the project, how we got to where we are and where things are going in to the future.==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========Github: https://github.com/uutils/coreutilsWebsite: https://uutils.org/==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm as always your host, Brodie Robertson. And today, we have, I guess, do you call yourself the lead maintainer? What do you call your position in the project? It's a good question. It's a lead of your utilities in general or the benevolent dictator for life. How it is called in other project? So yeah, we have the BDFL, the lead maintainer.

whatever term you happen to pick of this day of the UUTils project. I feel like a lot of people probably have heard of the project, but how about you give a brief introduction of yourself, who you are, and sort of what the project is, and we can go from there. Sure. My name is Sylveth. I've been working at Mozia for 12 years, and it is important because Mozia is a company that created rest.

And I used to share an office with one of the lead, of rest and we have been discussing over lunch for years about rest and when COVID happened, I was like, oh yeah, it's a good opportunity to learn rest. So I started looking at project. You know, I'm not a student anymore as you can see on my face and I don't want to do a project that is going to disappear. So before that I worked on Kling for Debian, so using the Kling compiler instead of GCC. And I found Korytiles and I was always interesting to learn how it works. And I saw that it was full of assembly. And of course, it's not, it's C.

So I found a project that was abandoned, and then we started it. So first we worked on the core utilities, but now we are trying to implement all the core tools of Linux. Right, that's an important distinction. A lot of people consider UUTILs as just a core UTILs re-implementation. But at this point, I just hovered over the project section on the website, and there's a lot of things on the list now. And some of these are, like, Find U-TILs is obviously a collection

of a bunch of other U-TILs. At this point, how many things would you say are included in this re-implementation? Well, I think we have 10 or 15 projects. Of course, the main one is for Scoroteers because we are not shipping on Ubuntu,

Microsoft is now proposing it for Windows, so it's the most mature project. But, uh, Microsoft contributed grep, the implementation of grep. They contributed some patches to find. So many of those projects are now mature and us to be used in production. Some others are not at all, for example. The re-implementation of Oaks, I don't recommend you start using it.

So it really depends, but we are playing the long game here. It's not something. There is no rush. We don't have any time frame. We have plenty of contributors. So it will take the time that it needs. I'm from the deviant community. We like to ship stuff when it's. It is really.

Right, right. It's the same here. That's how many projects it was. Do you know how many actual individual tools that breaks down into? So Currie Tools is like 70, 75, something like that. Find is 6, 5 or 6. So for example, for fine, you have XR, you have locate and update DB. You have obviously fine.

For Shadow, which is a group. group and user management is probably 15 tools. All can prep are only one, for example. Said is also only one. So it depends. But we have been trying to avoid duplication of code. So in CoreTales, we have a common crate. So a library in the rest ecosystems called UUKR

and UUQA and use where we share some of the common coding. So for example, passing some output of some common for so we are trying to avoid duplication of code. Right, right. Things like input parsing and stuff like that. Like that would be fairly standard across all of the different tools. Yeah, open file in the safe way, those kind of things. Right, right.

Okay. So, I guess, how did all of this get started? You said you learned Rust during COVID, and did you just jump right into doing this, or was there something else you did? and did you ever expect this to get the sort of attention it's gotten? When I worked on we compiling Debian using Kling, I quickly realized that a lot of people were excited by that kind of project for competition.

So when you look at Klang and the history of Klan, you can GCC. Now GCC is much better than it was before Klan. So I think competition is always good. And you can see that also in the new Coriteers re-implementation. When you look at the number of commit and the activity, you can see that the project in the Gnu Coritius, we started because of the work. Like competition is always valuable with LC and professional, like it is in those two examples. So it's always great to have competition. But I was surprised by the number of contributions.

Like, for example, the latest release that we have done, we had 75 contributors and 15 new contributor. Now in total, we have 800 contributors just to. contributor just to the various core deals. And when you have Mark Shuttleworth or the CEO of Microsoft presenting your side project on stage at the Microsoft conference, yeah, I was not expecting that really. Yeah, it's funny to see the interest of companies and individual and hackers. Yeah, it's very happy to see the success of that project. Around how long into the project did you start seeing, obviously, you would have gotten

some of that like developer interest early on. I'm sure, you know, especially back then, there was a lot of, especially a lot of hype around Russ, sort of, it'd been around for a while, but it had now started to like really get developer attention. It was starting to get to a point where people could actually make a career doing Russ. So there's definitely a lot more excitement around the language at that point. But when did you start seeing that more, I guess, adoption kind of interest? Well, it took me basically a year to be able to boot a devian and to install most of the packages.

Right. To make sure that all the blocking bug were fixed. So what I've done, I had two goals at the point, three goals at the beginning of your utilities. The first one is you need to start devian, but with system D, most of the things are not bash anymore. So you are not testing the script too much. The second goal was to install the first four, or 100 most popular packages in Devian. Those ones have a bunch of postscripts,

so they are leveraging a lot of courteels. And last but not least was to build Firefox because it's my job and I'm part of the build team at Medea. I'm a director, but I'm managing the build team. So I know that we are using a lot, some of those tools. So that was really those three goals. And every time I was finding a blocking bug, I was going to fix it.

And after a year, I wrote a blog post and the popularity of the projects Cairo team. Do you recall the name of that? Where can I find that post? It was in 2011, I think. It was one year. Oh yeah. I'm talking with someone from Australia, so you know everything about lockdown and being isolated from the rest of the planet. So it was during that time, it was during COVID. I think it was in, where was it? It was in 2021 or 2022. I will share the link with you. Yeah, if you can find it. Yeah, it's March, I will.

It was March 9. Okay, March, March 9. Search engine, find something, you know, I'm not going to find it right. It's not, it's not, it's not super fun. I just wanted to show it if we could immediately get it up. But if it's, if it's, uh, be hard to find. I think, uh, Forenix, Michael wrote an article right after. Ah, okay, okay, yeah, yeah.

Um, yeah, I'd probably be able to find it if I'd look for it then. Util's 2021. Uh, okay, now it's funny. So I love search engines, but I look up 2021 and it's like 0.0.21 release. Like, no, that's not actually what I search. for. Doesn't matter. We'll move on for that. So that blog post in 2021, that's where the project sort of first started getting its initial bit of attention. Actually, I literally just found the Frontex post. Okay, here we go. Thank you. So, I went, I found the link and the post is

not loading on your blog. That's great. Okay, whatever. Not important. We're moving past that. Rasted too much time in this blog post already. So, where do things go from there? Because obviously, like, the big thing that people talk about now was obviously the adoption in Ubuntu. But what happened between the blog post and that point? And when... I don't actually remember when the Ubuntu thing happened.

So when I published the blog pod, I had plenty of contribution. If you look at the number of commit, you can clearly see the blog post. Then I did a presentation at first time also. I had plenty of people excited by that project. So those things really kicked off the popularity of the project. I think Ubuntu, they reached out to me like a year ago. So it took three years to be in Ubuntu. But many people have been running it in production for years.

I'd like also to mention that, you know, the Snap, the company, they are making glasses, connected glasses. They contributed a bunch of changes because they used that in their classes. And I purchased also the Linux version for embedded devices like cars, for example, they use also our implementation for years. So we had early right from the start. Because for them, for example, they can control what it is going to code. So if you use CP, for example, you know as a company building car or classes,

you know that you are going to use CP with those arguments, with SIM link or hardling, so you can control the user of those command, unlike Canonical or Microsoft, where the user are going to do some crazy shit all day long, so they can find some weird bugs. So the level of expectation is clearly not the same. Okay, I actually had no idea about that. So this adoption in the more general... more general purpose operating systems, that's a far more recent thing.

Yeah, mainstream is started only one year ago. People have been contributing, well, people have been packaging U-Utills, core-utils for a long time. You can find NICS version or Ark and so on for a very long time. But as you know, it's hard to have telemetry, so you don't know if you have five user or 5,000 or 10,000.

So it's always hard. So when you have people telling you we are shipping with your software, with our glasses, on our glasses, you know that it is more popular, and you know that you have actual user. And you can see with bug report, some of the bug report now are obviously written by LLM, but a few years ago you need user to give you BUD report. No, the computer science like a year ago,

when it was completely different without LLM, it was at that time. So you can see the popularity by looking at the data number of bug reports that you get and the quality of the report or the PR and so. And yeah, you have a good problem. Like when I opening good first bug, it's very common that it gets fixed within a few hours. Okay, wow. But fascinating. I guess a little bit of a, I kind of want to follow one of those threads.

You did mention LLM bug reports. I'm just kind of curious. I don't know if you ever, like, given a take on sort of like your stance on like, all of this AI stuff going on, whether you have a different stance when it comes to like AI bug reports versus code generation. I'm just kind of curious with a project that obviously has the level of option it has and is trying to be at the scale it's at. Like, what is your general stance here? Well, in my day work, I have been involved in Firefox security in the

security scope and the security space for for quite a while and I have seen what anthropic mythos can do Firefox was the first one to test it and yeah and I have seen that hundred now probably a thousand bug report security fixes for security issue and then fixes identified by those tools so you cannot say in what is it today in August 26, that they are useless. They find a lot of things. If you do the same analysis on Chrome, on Windows,

you will see that they're also fixing thousands of bugs. So they are extremely valuable for fixing security issue. And I also see that with the worst correct deal. We have security issue. Most of them are timing attacks or incorrect behavior in some cases where, for example, backup file or those kind of things. So we do have security issues. Some of them are not a big deal.

Some other, like, timing attacks on system with multiple users can be more painful. But I can see that often the reporters are going to use an LLM. So you can see it by the quality of the bug report, or you can see it because it is closed at the end. And you can really see the quality of those bug report and how deep they go in the analysis in terms of security. When do you think... Obviously, it sounds like you think these tools are useful for bug reports.

Maybe, I don't know, we'll get to code generation a bit. At what point do you think it got to that point? Because obviously the very early tools, you know, we can all remember what things were like five or so years ago. They weren't exactly that great. Maybe you could get you a recipe or something. But when do you think we got to a point where for security analysis, these tools actually became useful? At least from your experience. Well, with Firefox and Modia in general, we are the state of the art.

So it might be working. I can really see things changing. It started basically in February, March this year, where we saw a clear jump in terms of quality in the book report. First, the quality of the model, but also the quality of what we call the harness. So I think the industry, the specialists, they have learned that a model is one thing, but you need also to have a way to verify that the bug is actually happening for real. Like you don't want to the AI slope, you don't want that.

So you are trying to design your test case so that you can verify it. So for example, for the risk core deals, you want to verify that if you are doing a timing attack, if you run it, if you run the script 2,000 times, you are going to trigger it once or twice a security issue. And you can do that now with AI because you have, you write a good hardness or you write a docker plus three or five scripts that are going to execute that. So I think the industry is learning, but also the model I've been improving a lot over the last few. Okay, that does seem to align with what I'm hearing from, like coming out of the Linux kernel, right? I don't know if you've seen the recent posts about the network stack, the network team are just like flooded with reports right now.

And yeah, that makes sense. what about when it comes to as a development tool development system the sort of code generation side of things? So there's definitely usage and it's useful on the bug report side but what about the other side of things? So I can see a lot of

PR coming. You know, I will share a Twitch that some people know there is a dash, the regular dash that you get with your keyboard and there is a special dash with UTF8 and this one is hard to dive and it's very easy to spot those ones so I can see in the code

or you can see also the 10 lines comment on top of a function it's rare that a human is writing long comments or you can see the comment zero well with the exception of someone who is just coming out of university because I don't know

maybe maybe education was different for you but I remember when I went through my self-engineer education they really hammered in like really detailed comments. It faded away very quickly after that because it's annoying to do. Well, yeah, yeah. Maybe sometimes I'm being harsh with people saying, right, shorter comment, because sometimes it's not valuable to have a comment explaining everything. Right, right. But I don't see, like, six months ago, I could tell that it was crappy code,

but now the model are so good that the quality of the code is very good. So I don't pay attention if it is written by a human or not anymore. What I really care about is, is it maintainable? Like, can I understand the code? Is it passing the test suite? Is it improving the code coverage? And is it keeping the same level of performances? And does it has any potential security issue?

And now I can see that the model I've been improving the tools like codex or code code code or the other I've been also improving a lot. And so I don't mind myself because what I want is I want to be able to maintain the code. Like sometimes you have contributors who are going to stay in the community for a few years and they write two or 300 patches. Some of them are just there to have their name in the kit log, which is completely fine. But I have in that case to think about the fact that I'm going to be the maintainer of the code and the PR that they just pushed.

And if the code is fine, I'm fine. Also, there is one thing that is great with Rust. Well, several things that are great with Rust, but Rust and LLM. First, the ecosystem with Rust is pretty new. So we don't have all the legacy that the LLM have been trained on. And in general, the code quality of Rust code is very good, and we have plenty of tools. So when you, and of course, the type system of Rust helps a lot. So if you compile, you are almost certain that it's going to work and run the way you want to.

If you do that with CNC plus, good luck. And the LLM for that are really good because they can test. And if you write some rules like a pre-commit hooks, you run the coding styles, the linters and so on. You can be confident that the code is going to do what you think is going to do. Right. So there's one more thing I wanted to get to if we'll move past the LLM topic.

Obviously, you're a very established engineer. You've been doing this for quite a while, as we can tell from the, there's some greys in your bid. You've been doing this. Yeah, yeah, yeah. Not 25 anymore. So the point of getting out here is,

a concern a lot of people have is with more younger developers adopting the use of these tools, you might see a lot of, of the sort of knowledge and skills that were standard with prior generations of programmers. The sort of counter-argument against that is there was a time when people would examine the assembly output of their compilers. That's not something anyone really does anymore. The compilers would are a point where they are good enough where nobody even questions the output. So do you

have any concerns there with like up-and-coming junior developers? I have colleagues who are still watching the assembly code, but they are really the exception because they worked in a very specific area of the code base. I think nobody knows, to be honest, the answer to the question. As you nicely mentioned, I'm not that young anymore, and I have a lot of scars. I wasted days and weeks of my life on weird bugs and sometimes miscompilation. So I built my expertise with all the pain and suffering. And I feel that we are skipping that step for the new generation.

And the question that we are all asking ourselves in leadership in big tech is how do we do that right now? Like, how do we mentor newcomers? You cannot, if everybody is using Argentic and an Argentic works well, you cannot say to the intern or to the junior engineer, you cannot use that tool that you have been using at university. and all your peers are using. So you have to, you need to make sure that they get access to that tool.

But as you said, you want also the quality of the code to be there and the maintenance. So mentorship is a key, is really the key here. It is just finding the right balance between learning and being productive and doing good quality work and so on. It's difficult. I'm really wondering how, as an industry,

we are going to be able to train new generation. Yeah, programming is one of those ones where the, it's obviously a knowledge field where the output of the LLM is also the output of what you as a person would do, right? It's different to a field like music where if you're using, obviously it can generate music, but an LLM cannot play a guitar. it can teach you how to play a guitar it can generate guitar itself but that's kind of a different thing like that live performance kind of aspect

is separate it's a thing in the physical world where programming doesn't really have it to that same extent so there's yeah I don't know where it's going to go either I think anyone who's saying they know where it's going to go you should probably be concerned of those

I think just having concerns is a reasonable thing where we are right now, especially with how, like, I would say be just as worried as someone who has zero concerns whatsoever because, like, you know, these tools are at a point now where they are good,

and we don't really know what that ceiling is. Yeah. Yeah. I think it's also important to teach the best practices in terms of code engineering, like having a bug tracker, having pull request, having a good CI with a good test coverage and those things. Those things are still valuable even in imagine in a full LLM world. You still need those things because at the end you are producing the software that is going to be used by human. They might also be used by LM, but Corrie Thiel most of the time is used by human.

So you need to have someone who can understand what is this supposed to do for the users. Same for a web browser and email client and so on. So you still need at the end to have an outcome and you need to make sure that you understand it and you can maintain it long term. Like as I was saying at the beginning, we are playing the long game here. We are doing software that are going to live for 10, 20 years, 30 years. And those things need to be understood and maintainable. and it's part of the difficulty. And the skills that we have built over the years

are very valuable in that space. What is good good, what is maintenance, and CI coverage performances. So near the start, you mentioned that your initial goals with the project was basically get a functional Debian. Yep. What were you using as sort of your, I guess, guide towards that? just test suite completion?

Was it, like, when you started with a blank project, like, where did you start from there? So, so some people already contributed, it was abandoned, but I started a project that was started. So I already had the skeleton before.

Okay, what state was that in when you started it? Well, some program we're working okay, some other were not implemented, some option were not implemented. So everything related to localization and internationalization were not there. Performance were terrible.

Low CI, poor code coverage. And so, you know, the projects that people drop in the middle of the... Right, it's probably a project someone else picked up to loan rust and then just bring up to something else. Yeah, yeah, exactly. And I've been in touch with the initial maintainer. We have been exchanging email for the last few years. So the first thing that I have done with others was really new Corritils.

So you have to take a step back, we have plenty of Corrilles implementation. The first one, and you can see the source code, and it was written in assembly, is the one from Dennis and Kerrigan in 71, where Zerode Unix was on board. But you can see, you can find the assembly code online easily. I can share it with you later if you want. But if you see how it worked, it was working the same way. So for example, C.HO or C.HBod, it was using the same argument back then, so more than 50 years ago. So those tools have been around for a long time. You have other implementation.

So you have one on Apple, which is a BST one. You had some weird things by Microsoft. And then there is a gold standard of Gnu. And because everybody uses that one on Linux, I started by saying, okay, we want to have a 100% compatibility with them. And we are going to take our Roscode and run it against our test rate. So that was really the goal. And then discussing with some friends that Madias, it told me you should do a graph of that. So it has been what the press has been using every time we do a new release, they take that graph because it shows the evolution of our time of the competitive.

Some of the changes were one line, well, more because you want to write test, but some of the changes were only one space in one file, and some other required months of work and refactor and so on. So it has been really the way we started, so having a full drop-in compatibility. And then we have been noticing that for many programs we have 100% compatibility with a test suite. test suite but we have a report sometimes of people telling us in that program in which you have 100% compatibility you have that different behavior so every time those things happen we forward the upstream so we write test and we are going to send them to uh to the new project and they are quickly accepted because it's improve everyone's uh project so it is what we have been doing a lot lately So I would assume it's a mix of undocumented assumptions and bugs that people rely on.

Yeah. And sometimes it is, if you use that argument, that argument with that kind of file, you are going to get that different behavior. So you have so many options with CP, LS, LN and so on. Everything related also to internalization. So as soon as you start touching with in French with action, with accent, German, with umlaut, and then you start moving to Arabic, Japanese, Chinese. You need to be able to handle those.

And then you have also all the incorrect encoding. Sometimes you have, Gnu is going to behave in a weird way with some incorrect encoding. So you have to replicate that because you never know what can happen in the wild. So you do that. You have also a funny way to do it. It's one of the things that I learned at Maze

working with fusing is that you can do differential fusing. So fuzzing basically a technique where you send correct and incorrect data into a program. So that can be a function, but that can be also a program. And the differential fuzzing is that you generate plenty of weird commands and you verify with a new implementation and then how else that they give the same STD out, STDR and the same error code. And then if you have a different behavior, you can trigger an error and break XOCI because the fuzzling is going to find differences.

So one good example is the date command is a nightmare on the system because you have so many options, you have so many times on it's really impossible to get it right. It takes forever. So we have been doing differential fuzzing and sometimes the fuzzle is going to find some things that you didn't know and like, oh yeah, it's a military time zone in that place, in that moment. You know, in some countries, they have 30 minutes time zone also, those kind of things. Yeah, I know. That's why. So, you have to manage all those things and it's so difficult sometimes. I assume, I don't know if you are aware. There is an unofficial, is it 40, give me a second,

Australia, 45 minute time, yeah, there is an, yeah, UTC plus 845. Where is it in Australia? That's along a highway in Western Australia. It sits between Western Australia and South Australia, and they just split the difference. Weak consensus. So yeah, you have to manage all those things, and then you have also some weird calendar.

So I think Newer only recently started supporting it, like in Iran and Thailand. they have different calendar so they don't, they are using two kind of calendar with different year start. So you cannot make the assumptions on a Linux, everybody's in 2026. So you have to manage those things. Fortunately, the rest ecosystem is very major so you can rely on some crates who have been doing already the work before. Actually, on the topic of crates, like what is what is sort of the policy with crate usage

in core utils there's obviously going to be a lot of crates to do a lot of different things out there do you just adopt crates like whenever are you very particular about them like what is how do you sort of handle that

good question so now the ecosystem when we started that work the exe exploit didn't exist. So I always been concerned about supply chain attack, but it was not very concrete now that it is. I'm way more careful than I was before. I always been careful because you don't want to depend on a crate

that is not going to be maintained. And you want to depend on a crate that as users. If you are the only user of a crate, it sucks. So you really don't want that. So when someone is opening a PR and say, I want to add this crate, we are going to monitor the impact on term of file size. We are going to look if it is well-maintained upstream. So basically how many, how often PR are stuck? How is it to get a PR merge upstream?

Who is a maintainer? Is a maintainer anonymous or not? And then we are also going to look at the number of people who are relying on a crate. So for example, if you know that Chrome or Firefox, it depends on it, you can be sure that if some maintainer disappears, you will have some other people who are going to take care of that. If you are the only one who rely on a crate and the person disappears, it's not a great experience.

So you have to, you need to contact the maintainer and say, can you give it to me? That happened a few times. So for example, we maintain a crate called NUM prime. That is going to evaluate if a number is a prime number or not and give you, I don't know how to say it in English, but just the number to read that prime number, the multiplication, and that stuff was maintained. So I reached out to the maintainer, and the maintainer was like, oh yeah, fine, you can get it. And so you can reach out to the maintainer to get it at the end, but it's very work.

You became the maintainer or something that you didn't want to maintain, but you are doing the right thing for the community. And again, if you rest, it's quite easy to maintain as a maintainer because of the quality of the compiler. You can trust the code that you get. But sometimes it can be hard. You have to be careful. So what are the kinds of things that you look at when you're considering crates? Like what sort of problems are worth getting a crate for versus just doing it yourself? Well, I'm lazy.

So if there is a good crate, I'm going to use it. I think it is one of the main difference that we have with the CNC plus ecosystem world. It's very easy to add a new crate. Like if you have done any cross-platform development with CNC++, I like to have to people like think about you want to do a program that depend on an XML parser and so you can do it on Linux like you are going to use C-MEC, you know okay one Mac is going to probably work fine. And then if you want to support it to a Windows or Android or free BSD and now it is a time where you start crying because you don't know how to declare the dependency against the C and C++

library where are the their file what you need to do, use and so on. Sometimes you don't even have a C compiler by default. So how do you do those things? And it's terribly hard in CNC plus plus to do that. So that's why you see a lot of programs shipping all the third particle directly inside. For us with the Rust ecosystem, it's very easy to add a new dependency and to and to make it cross-platform. Like writing cross-platform code with Rust is super easy.

It is one of the strengths. So if there is a crate and it's well maintained, I'm going to use. use it. Like we don't want to duplicate the work. And in many cases, we, we work with upstream to fix some bugs or provide PRs and so on. So it's benefits to everyone. Let's get into the topic of Russ then. Obviously, you know, we could just end the conversation that you're involved with Mozilla, therefore Rust. But like, what was it about Rust that made it seem like the language to go with for something like this. For the West Coritals?

Yeah. Well, it's, so to take a step back, but they are created Rust because C++, because of two main reason. C++ is very hard to write it safe. Like, it's very easy to write security issue in Rust, in a C++. It's very easy when you look at all the bugs that Mito's and the new LLM has been finding. Most of the time it's a memory management issue. Like one of my former colleague Alex Gennor wrote some paper about the number of security issues that you see in C&C++. It's 60% of the time it's memory management.

Seeing that the language should protect you from by default, like with OCaml or Ada, or those modern languages. So that was the first reason why Moodya created it. And the second one was parallelism, writing parallel code in CNC++. It's extremely difficult. You really have people who are going to say, I can do it. And at Mozia, we decided that we cannot do it. And maybe we are not good at us. But we decided that we prefer to create a new language to make that better and safer for all those two reasons.

Well, you can definitely deal it, but you contribute to the 60%. Yeah, yeah, yeah, exactly. Especially when you get into barrels. You're really going to start having some fun problems there. Exactly. And so when you think about first at the end, it is going to write binary with LLVM, like to go into more technical aspect. So when you compile some OS code, it's going to call LLVM,

and it's going to generate assembly code with that one. And if you look at Kling, the compilers that everybody uses to build browser, now, Kling is doing the same. It's going through LLVM and chenering binary. So when you think about it, you're like, yeah, it's the same. You're taking some input and you're generating thing assembly. And I knew from my time at Mozilla and the work that I'm doing over there, that Rost is very good in terms of performances and security.

For example, when we looked at the stats that we have with the fuzzing, we know that running a further on ROS code is not going to find that many security. And like if we write a further and it's targeting some C&C++ code, it's going to find plenty of security issue in general. So of course, the Gnu Coritiels have been extremely safe. Like there is no security issue in general with reverse Coritiels. But really what I found interesting is thinking about our industry and where it is moving. moving and I feel that you were talking earlier about the new generation. And the new generations, they don't want to write C.

Just like me when I started my career, I didn't want to write cobalt or Fortran. I wanted to write C++ or Java because it was a high or Python. Java seemed like the language around about that time. Yeah, exactly. So I wanted to learn those languages and I'm sure that the new generations, they don't want to learn C's. They don't want to be paid to write C and C++. They want to be paid to write Swift, Cotlin, or Rust. And you have to think about where we want to leave the state of computer science to the next generation.

And I feel that C and C++ is going to be less and less relevant for the future because of those reasons. It's way more exciting to write Rust than it is to write C, in my opinion. I'm sure that some people will disagree and that's fine. But it's very funny to write worse because you really have a good understanding of what it is doing. And the code is very nice to write and so on. When I write C and I've been writing C my whole career, I still write C plus person time to time at work. I know that I don't understand everything that the compiler is going to do. And I need my colleagues to tell me you fucked up here.

You are going to introduce security issue if you do those things. of course we have tools that we have developed or used to to analyze those mistakes but with Russ you don't make those mistakes when you write God

so I think this is why I think Russ is very relevant for the future like it allows a new generation to contribute to those projects I think that's one of these things I've been talking about I feel like I was I was sounding the alarm

for this before anyone was even remotely discussing the idea that whenever I said I've been talking about the idea that like C is going to slowly fade out with the next generation of programmers I reckon I was talking about like six years ago before anybody else even want to acknowledge the problem

and I've been proven right now right like every obviously C is still a massive language but what I have been seeing is a lot of people who are really established C developers C++ developers who end up doing something in Rust,

they realize how dumb it was to have to worry about a lot of the problems that they were worrying about. Hang out with anyone in the Linux kernel graphics stack and they'll tell you how much C, sorry, how much Rust is massively improving what they're doing and they don't, what, they, they, they, They maintain the sea because it's there, but they don't want to start any new drivers in sea.

Everything new. It makes sense. Rust is just going to be what they do. When you are a reviewer, you don't have to worry about memory safety. When you see a reverse code, you have to worry about certain classes of problems, but you don't have to think about garbage collection,

manual, rave counting, and all the things that are managed by the language for you. for parallelism you have. The language is protecting you. So it makes me easier. So let's get into some of the sort of, okay, let me get into some of the arguments that people make against Russ,

and I just want to, I just want to like, I'm going to play devil's advocate here just to have some fun. So let's talk about unsafe. Because I feel like there's a lot of complete misunderstanding of what unsafe in Rust actually means. They hear people talk about memory,

safety, rust is safe, and they see big blocks of code in unsafe, and that just blows up their brain. So unsafe basically means that it's a way to tell to the compiler. I know what I'm doing. Don't worry about it. It doesn't mean that it is unsafe. It is just to tell to the compiler. I might be doing some weird shit. Don't be surprised if I do that. So for example, we have a lot of unsafe. when we need to call system libraries. So let's say that you want to change the permission on a file with SEDinux. You are going to do an unsafe, either in your code if you directly call the library or through the crates that you are relying on.

So you are just those operations are unsafe. Another example is, you know, the environment variables that you have. Like, we have plenty of those. The function to set an environment variable is consider as unsafe in rest. So you need to put the unsafe because if it is running in a parallel way, it might do some weird mismatch or you don't know exactly what's going to be the value. So it's just a way to tell to the compiler it is, it might be unsafe.

So let us let me under that the way I want. But at the counter argument, like you know you if you look at all the LLM bug report that the industry had had. If it was really a source of security issue, you would know by then because all the LLM would have found it. Like Meadows would have found tons of bugs related to unsafe. And it doesn't be the case. Like when I looked at all the security report

that MAD has been publishing on Firefox, and I'm sure that the Chrome Steam is going to share the same thing. There is nothing in Rust related to unsafe. Like you might have some timing attack, like you create. file and then you use it and in the middle you can do some weird action but nothing is related to unsafe like I haven't seen any maybe I'm wrong and if someone sees that please send me an email I'm going to be curious but unsafe doesn't doesn't mean unsafe in in the way we are

talking about memory safety in that case it basically just means let me do something stupid I know what I'm doing don't worry about it it's not even stupid this let me know let me some things that I know that I have to do it this way. Right. Like, yeah, as I said, linking with a library, a native library, sometimes you have to do that to do some CISC call and in that case it is unsafe. And if people are into security, like just try to run it on the best core deal on the end of and save part of the code.

I don't think you are going to find anything, but I would be curious if someone can challenge me on that one. I guess it also acts as a sort of self-documenting block, right? Like, if you in C, the entire code base is effectively considered unsafe, whereas

like, you don't, if you're just looking at the code, you don't know without examining what the code's actually doing, if you're handling things in a memory safe way, but with Rust, if you did something wrong, you know it is in

that block. Yeah. Well, uh, we we try not to do memory management ourselves. In some cases, you have to do it for when you need to send some data to some Windows API. So you need to do it, whether it's memory safety or timing stuff, whatever it may be. Yeah. Well, it's the timing attack, they are not, they have not been in a unsafe. They were more core issue in the rest of STL.

Because, you know, it's a... So compiler cannot guess that you are going to create a file and then change the the permission so you cannot do that at the at the rest level so you need domain expertise to know that there is a potential timing attack and it was it's quite far the biggest class of security issues that we had in service courteals so and those things you cannot they have not been in unsafe part of the cut they have been in the rest itself and but it's just the nature of the work that we are doing working with files it's dumb but it is what we are doing you have that in every language it's not specific to rest thing that often comes up is people will often say if the code compiles you know the code is obviously not perfect

but you know the code is good you know the code is correct I'm not sure the word is there but you'll often hear this and I think a lot of people sort of misinterpret this idea as if the code compiles there are no problems what

whatsoever. So what are the kinds of problems that Rust doesn't try to solve? Well, the way I phrase it is logic error. Like, Russ cannot know, the language cannot know if you are making a logic error. It's going to help you with programming mistakes, like memory management and variables copying and, you know, the power checker and all those weird thing in Rust. that makes REST unique. So they are going to prevent you from making those mistakes. But then when you are implementing the core of your business,

so what you want to do actually with your software, Ross cannot know about those things. So if you are making, let's say, if you are working on an accounting software, and instead of a multiplication, you use a plus an addition, the compiler cannot know those things. And it is you as a human that are supposed to know

what you want to do as a software developer. So those things cannot be prevented by any language. Maybe now with LLM, the LLM is going to tell you here. You meant to do an addition and not a multiplication, but we are not there yet. And the language obviously cannot know what you are trying to achieve. So it's really that. It's the logic errors.

And another big one that comes up is regarding platform support of Rust. Now, I know this is a dumb one. one. Anyone who looked at the platform support list of Russ knows this is a dumb one. I just, I had to bring it up though. So, obviously, when we

look at Rust, it does not support every single platform that C has supported over the years. But is there anywhere where there are gaps that really matter for Rust? Yeah.

Yeah, good question. I think it is one of the advantage of having the Linus kernel using Rust is that if people really care about porting Rust to some weird architecture, they are going to do it. I didn't say that, yeah. It has not been an issue for me because my initial target was Linux Distro, and they are also supporting LLVM. Basically, if you want to port Rust to an architecture,

you basically need to port LLVM to that target. And you can also do cross-compulation. So sometimes you don't even need to compile on the actual hardware. You can do cross-compilation. So that works very well with Rust. It's super easy to do cross-compulation with Rust. So it is one of the advantage of the language also. You cannot run it, but you can compile it.

And at least you did a good trunk of the work by doing that. But yeah, I think the ecosystem is moving towards us. So it's just a matter of time for all. for some architecture to be supported. I don't think it's a big deal now. It was one of the first counter-argument when the Russ community tried to get Rustes into the Linux kernel. I do remember this.

What about my real architecture and that the last CPU that has been produced for that architecture was 10 years ago, but I still wanted it. And that might be a problem, but it's part of the evolution in our industry. I do get it. I do get it right because the kernel does have a lot of weird platforms

I remember I think it was like maybe a month or two or three months ago Afronix put out an article about new drivers for the Sega Dreamcast being up like I firstly who's

I didn't even know you could do Sega Dreamcast Linux apparently you can who's working on that like somebody has just decided that's going to be the thing that they spend their time on and that's cool That's cool. I love there's somebody out there doing that,

but what are you doing with your time? Yeah, yeah, yeah. Well, I'm re-implementing a core piece of Linux with my time that works well already, so I'm not going to blame that individual. Sure, sure. Well, I guess that's another sort of one. Moving away from Russ, like sort of directly related to this project, why bother, right?

because we have this version of core utilities that's been around for a long time. It seems to be solid enough. Yeah. Yeah, it works away. Yeah, I love it. Like, why bother? Well, the first and correction for you is, why not? It's a...

Yeah. First, I wanted to learn how the operating system works. Like, I know a bit about compiler and web browser, and I didn't know much about that part of it. of the operating system. It's a great way to understand all the weird stuff that you can do with those tools. And there are plenty of weird behavior that comes back to the beginning of computer science or the modern Unix, well, modern, 72 world.

So it is quite interesting in that space. It's also fun to be working with plenty of smart people, plenty of people coming from all the planet. But as we were discussing earlier, one of the key thing is a contribution. Like you you want people to be able to maintain it and to publish new version after I'm gone and it's probably going to be better in RAS than it is we see. It's easier. And last but not least, performances, like you can really see performance improvement by rewriting that in Rust because you are going to rely on some creates that have been easily optimistic

optimize or some creates that are or some rest feature from the language that are directly connected to the last feature of the Linux kernel, like Splice, for example, some very advanced way to do some file operation or to do some math or SAC optimization for some algorithms. So you can realize that. So you can get some much better performances for many, many of the Corriteers program. We are much faster than the new implementation, not because they are doing a poor job. It's because it's easier for us because we can leverage the ecosystem. It's easier. We don't have to maintain some weird operating system with only a few megabyte of RAM. So we can, we are, we have some advantage of them.

Okay. Okay. I was trying to think of a way to segue off of that. I guess we can jump back a little bit to test suites. So where, like, okay, so right now the test suite pass rate is, according to the graph, 93.2%. Yep. I assume at this point most of the low-hanging fruit stuff is kind of dealt with. What is, like, what sort of.

makes up that last couple of percent and I guess also there are these points on the graph where the fail rate did go back up a little bit I guess if you could explain what those were as well sure yeah that'd be cool so the why is a fail rate increase is because upstream uh push some new test or sometimes I push test myself that I know that are going to fail with my implementation So in some cases, in many cases, I'm going to add a new test to the new test suite. While I know that my implementation is not working properly, and sometimes I fix the issue before the publish a new release. Sometimes I don't fix them.

So that's why it's just, how do you say, a self-inflicted wound that I do. But at the end, I don't care. I know what is the state. And what is remaining, some people might say it's the art stuff. It's not the art stuff, it's just a boring stuff that we make. One of the example is what should be the behavior of a command that shows something to the terminal when the output is full. So basically if you do a LS and you redirect to a deaf full, we are often panic. Panic is a nice word in rest.

It is just that the program is going to fail by design and nothing that can happen in that case. And because it's happening at the STL, so the standard library level of rust. And it's a good thing, but we have to handle that case properly and to generate the same error, and we have to fix those things. There are also some weird stuff with some encoding or some corner cases with some program with cut when you use the specific UTI to local, the sort is not going to be exactly the same. So it is those kind of things that are still happening. There are also some stuff like if you limit the number of file open on the system

and you run the command, what should be the behavior of the command? Like should it fail gracefully or should it explode? And it is those kind of things that never really happens in real life, but the new core details have tests. And there is also another one that I love is date dash dash dash dash debug where the date command is going to tell you why it decided that it is a time and date where you are because you know in australia you have some weird time zone and uh and sometimes the the tool is going to tell you it's because you are in australia and you are in daylight saving

plus something and there is a take debug option and we have not implemented that one because it's it's it's super fun to do and it's not very valuable. So there are cases where we didn't do the work to implement it or some stuff that we don't care like all the operating system. So to me we are to me it's going to be like feature complete at 95 something like that. We still have a five or six test that I'd like to fix. So rest I don't really care and when I see people on various website thing that we need to reach 100% I disagree because there are really color cases that really happens in real life. I think as a sort of similar comparison point to that, GPU drivers and Vulcan conformance, a lot of drivers

that people rely on don't necessarily have a hundred percent conformance because there are some real weird, I don't remember how many tests Vulcan has it, some stupid number. Or like browser web test conformance. None of the browsers have 100% conformance. Literally not a single one of them. Because there are some real weird cases out there over 30 years of weird browser development we've had.

Yeah. But the main case, not even just the main cases, but the path of like 99.99% of usage, I guess. Yeah. It's good enough. Yeah. And at the end,

like you know, when canonical ships the first version of Ubuntu with our implementation, I must have been that I was scared. And because I were like, what did I break? And we had, we had regression for sure. Some of them,

a few of them, a couple were quite painful. But at the end, you can see that we didn't have that many bug report because of different behavior. Like, I was expecting some more insert online, and I only had a few. So that's pretty good. That shows that it works for the vast majority of the case.

Like, we are not fully compatible, but we are still way more compatible than the Apple implementation or the BSD one. So we are still very close to the gold standard. And we are also making the gold standard better. Look, I haven't mentioned Microsoft. To be fair, BSD isn't trying to make a new compliance. I'll let them off the hook. They're trying, they're happy with POSIX compliance.

Yeah. Yeah. So, I actually don't want to get into the Ubuntu adoption because that has led to some, I guess, how would I, what's the best way to put it? Some very public problems, right? like there will be a like some issue that gets noted like I think there was an issue with like building the ISO a while back

some other things and this becomes like a very like big topic so I guess how do you sort of navigate that and I guess also were those just like one-off things because a lot of people sort of then assume they they sort of expand from that point that there is this problem therefore project in its entirety

is broken like this is doomed to fail kind of thing well i i have been a devian developer for almost 20 years and i always care about ubuntu because ubuntu is derivative of debian so all my work in debian is going to reach ubuntu so i do care a lot about that that is true right and uh so what i've I have seen, I think, three cases of big bugs. One was an unentered in upgrade. So when you want to upgrade your system, we had a bug in date. We had the one that you mentioned. Of course it's date.

The one you mentioned was a problem. Yeah, of course. And the last one was we were generating a slightly different output. And one of the Linux kernels test was passing it, we're trying to pass the output. and because we were giving a slightly different output, the test didn't work. So that really is the three cases that I have seen that were quite popular in turn negative, but many people are running.

It's probably the most popular Linux distro in the world, and if it was failing everywhere, you would have known by now. So I'm sure that some cis admin are reverting to GNU, and that's great. But at the end, if you want to test the story, software, at some point you have to go live and to detect those things. And those regression have been identified. And in many cases, maybe not for those three, but in many cases, the regression that we have identified are now part of the Gnu test suite.

So it's also benefiting from the Gondotest suite. And at the end, canonical also when they made that change, it was also for the same argument that we need to think about contribution and new generation. And using C for the next 10 year might work, but we have to think long term and versus is clearly the way for all the base component of our operating system to go. I believe they're also experimenting with pseudo-RS as well, I believe. And that's for, pseudo has notoriously had a lot of privilege escalation problems, and notably because of memory issues in the majority of cases.

and like obviously Sudo is a great project but like I can see why they would want to sort of a try different approach to this especially for something like that and for how important Ubuntu is and how many businesses rely on it. Yeah. Well Sudo is a good project. I think they took a different approach

than the one that we are taking with the utility is that they are more aggressive in this. enabling features from upstream, but it's the same approach at the end. You want to give the same interface to the user as much as possible with a safer way. I think the fact that there hasn't been more problems with the U-U-U-Tils is sort of a testament, right? If it's being there since 25.10, it's not blown up in people's faces. people haven't just abandoned Ubuntu because it's like unusable now. Like it's for the most part, besides those very notable cases,

it seems to have been a mostly transparent adoption. Yeah. Yeah. I have plenty of colleagues that are using Ubuntu at Madia and they would have contacted me if it was really terrible. I have some friends who can tell me one of the ones. I'm doing things wrong and they didn't tell me. So I'm good.

I'm giving that. So let's talk about the license. I assume that when you took over the project, it was already MIT licensed. Yeah. So I guess with it being MIT licensed, you could have reliccences it to something else if you wanted to. Yeah.

Why did you stick with MIT? And I guess to extend upon that, there's also concerns people have around moving a core part of Linux assuming other distros adopt it who knows what happens there moving it away from a GPL license project to something that is permissively licensed

with the MIT license well first I don't care that much about licenses so that's why I didn't I didn't change it because what I want is that stuff to be open source. Like I want people to be able to access to the source code and then modify it. I don't mind when people are taking it to do proprietary stuff. Like it's not, I don't care.

I prefer that people use my software and have fun with that and not using it. So that was one of the first reason. The other one is who cares about the rest of course. Like there is no money to be made in that space. So Microsoft is not going to fork it. And to make money like it's not a selling argument. So it's not something that a company is going to fork and sell it. So and so the size of the communities that we have now is a testament to that. Like there is no point because at the end you want people who are maintaining the code and who can make it leave and it is really where the value is and it's not in the last. So that I do understand why people feel emotional about that. I know that you did a great video about the subject in Devian and how people perceive it and the threat talks for like 20 emails or 100 email about the license of

oh that one yes yes sorry no no no no no no it's not the MIT versus GPL debate yes yes yes yes at the end is uh nobody is going to 40 them to make a proprietary version of that like it's not interesting it's not challenging and uh it's There is no money to be made in that space. It's not a competitive advantage for anyone also. I think the argument definitely could have been made in the 90s, in the early 2000,

when there was definitely was a lot of measurable hostility from companies like Microsoft. Like, we can go back and look at the Halloween documents. Like, everyone knows what Microsoft was like back then, like actively on record wanted to ruin Linux. But I think a lot of companies have realized that there is, I think Google played a big part of this with Chromium, realize there's a lot of value in having the code be open.

Even just for the, like, you look at it in the most, like, boring, like, money-focused way, the fact that you don't have to pay these developers to work on the project for you. Like, I think a lot of, even just that by itself, I think a lot of companies have realized there's value in that. Plus, you get the benefit of some, if something is open, more people are willing to also do security analysis and bug reports and actually, like, generally just improve it. Yeah. Well, you can see that also in the LLVM and the Kling ecosystem. Like, now it was started by Apple.

clang by chris latner back in the day but now everybody uses that and everybody contribute to that project and you can really see that happening with rest also the programming language it's just to be a mozia project now it's a foundation and uh every big tech is contributing to that project for for you till i can see people from canonical or meta or snap or Microsoft contributing to it because it's again as you said it's not a competitive advantage for that them and this is a value of having other company contributing to that, to share the load. And also to have compatibility, I think it's also one of the advantage is if you have those tools shipped on Windows and Canonicals, that makes supporting support to that new platform way easier.

And the same with LLBM and Klang or rest itself. If everybody uses those tools, that makes the port. portability much faster and much easier. Yeah, okay, fair enough. I have rational argument about those things. No, no, I... Not dogmatic. No, I...

You know, every time I... Every time the topic of MIT comes up and this topic especially comes up, you always get the... I'll probably have comments on this mentioning like AAA, and various other things. Like, I get the concern, but I also, I think,

with a case like this, I do sort of align with what you're saying. I don't really think there's. Like, yes, like, Microsoft could make a internal fork and release it and call it as your utiles, like, okay. But, like, why? And also, if they did, why, like, it, like, why, firstly, why would they do it?

Secondly, what reason is there to use it? It's not like, if Microsoft wanted to make a competitor to core utilities, like they could, right? Yeah. Like, they, yeah. Like, that's, I sort of get why you're kind of like very, very lax on this. It's not really super important to you. Yeah.

Well, at the end, if Microsoft wants to for kids, they could, but they would have to put resources on it. and engineers are expensive. At Microsoft, they are very well paid. So, as I said earlier, we had 75 different contributors on the last version of Coritiers. Microsoft would not allocate that many people on it. They would allocate one or two or three percent max.

And what's the point? At the end, they diverge. They would diverge compared to upstream and compatibility problem and so on. So there is no point. Like we, in 2026, we are not in the same world, as you said, that we were 10 years ago. Now, it makes no sense. There is one concern the license does raise, and that is the actual process of doing the implementation. Because the Gnucal users are obviously GPL, is it V3 or later?

3. Yeah, V3. Okay. I'll be it. I'll be sure if it was V3 or later or just V3. there's obviously you can't just like take you couldn't just like take the code

and then just convert it to Rust and then just be good like that's how do you sort of approach this problem like would how do you navigate this issue I only look at

the new C code when I want to fix a bug and if anyone wants to have a look if you look at the C implementation and the rest implementation, they are nothing like, they are very, very different just because of the nature of the programming language. And the fact that the new implementation relies on Gnui,

and that's it, they have a few other dependency, but they are mostly self-contained. And there is also a lot of C code just to do some C stuff, like memory management and those things. So the code is very different. So, but I had the case this morning, someone who clearly took, we used an LLM and clearly asked the LLM to look at this implementation. And it was too similar to the original one.

One of the GNU upstream developer told me that, which had to me, and I closed the PR. And I finally added an agent.md at the root of my repo saying, Don't look to the LLM, don't look at this implementation. Don't use that. So yeah, yeah, it's, we are not going to, to look at their implementation. And also it makes no sense because it's very different. And at the end, you want to replicate the behavior of the program.

So you just have to call the program to see what should be the behavior, like to use a date comment one more time. If you use an environment variable plus argument, you want to look at the output, the implementation doesn't really matter at the end that much. You really want to focus on the output. Okay, fair enough. A lot of what we've talked about is getting it in line with the GNU implementation. However, you've also been sort of discussing the idea of doing things better,

improving upon what was there. you did send me a PR in emails before if you want to sort of get into not just being Ganoe so we have things that Gnu has been refusing to do for years and I think they will change their mind but for example

the dash dash progress option on CP and MV like everybody who touch your unique operating system did the CP of a big directory and you have you have no way with CP itself to know if you did the 5% or 85 and that's a pain. So you have to start a new terminal and then you do a DU to know what has been copied or not.

So we added that option to our implementation. We are very careful when we add what we call extension to our implementation because we know that, especially that now we ship by default on Ubuntu, that we don't want to cause problem to others distrault that are not using our implementation. So we don't want people to rely on our option. The thing that you were referring to is it was an idea by one of the maintainer of our re-implementation of Hoke. And he had the idea of providing better error messages to the user. Because some of the comment can be very cryptic, the error message.

So I stole his idea and I'm like, oh, I'm going to do that with the knowledge of it. So the PR that I sent to you is for CHMOD. So the command to change the file permission. So the format is cryptic and sometimes you get some dumb error messages. So now we want to improve the life of the user who are using the command. Another one that I want to do next is test. So the command that you use all the time when you are doing BAScript. It's a pain to write.

Like for example, if you want to compare a string, or number, you are using a different way to do those things. And that even for experience developer, it can be a pain because you never remember which one you are supposed to use. So I want to give proper messages. Like, for example, if you want to compare the number with another number, and if you use equal equal, for example, you say, no, it's not the way to do it. It's a dash EQ. And you want to pinpoint, you want to point exactly to the exact character. to the user of that.

It is the kind of thing that we can do to improve. And one of the tricks that I've been using is only if it's from a terminal. Like if you are in a script, you are still going to get the ugly old error message. But if you are running it in a terminal, you get the fancy 2026 error message. And if you look at the PR, it's leveraging a crate that already exists. I don't know how to pronounce it, but it's called. are you at needy or something like that. And it's providing everything for you.

So you don't have to be implemented yourself. You already have a crate. The Diff is probably a few hundred, it's 100 line. It's way less without the test. But that makes it very easy to understand and to maintain. So it's one of the advantage of leveraging the rust ecosystem. I don't think it is nice to be able to like sort of I guess

pushed the other project to get better, right? I don't know if you've already thought about it like this, but it's, I would hope it to become a relationship like exists between the NeoVim and the VIM project, where for a long time,

VIM was very, very conservative on merging anything. But NeoVim brought in things like parallel plug-in parallel plug-in support, they brought in like

Lua configuration, like all of these other, obviously these are like way bigger changes than you probably do for something like this, but there's still improvements that you can make that sort of improve the experience without necessarily fundamentally changing

the core of what it means to be using it. These are things that improve a user's experience. with it, but don't necessarily change fundamental workflows. Yeah, the issue is that you don't want to break the script that people have been doing, so that you have to be careful. But there's some time we forward bugs to upstream also, to the new project, so that they can fix some bugs. And I know that they have been looking at our bug tracker, so sometimes they see what we, what we do, and all the kind of bugs that we have and the right test also.

So we, yeah, and I know that we have been discussing, like, there is all those weird checksum command on Linux, and we have been collaborating on those things. I didn't follow that closely, but I have some of my peer and new utilities who have been collaborating with upstream to deprecate some of the BHA together. So it is for the best. And I have plenty of email exchange with upstream, with Zugnu project, and they are very nice, and we collaborate. You don't like the MIT license, but that's a different subject. So, as this project continues on, what is your ultimate goal? Like, I don't know, five years,

assuming you're still working on it 10 years from now, whether you'd even want to work it 10 years from now. What is, like, do you have some, like, far-out goal you want to reach with it? One of my goal, I've been talking with some friends about it, is to make sure that it is not my project. If I die tomorrow, someone else can maintain it and the project doesn't die with me. So this is one of the things that I've been trying, like the governance of the project. I started some conversation with some friends that what would be the best host and so on. Now in terms of technical level, I could like all the major comment on Linux to be

to be in rest and potentially to be under our umbrella so that we can short code and best practices. So I mentioned Oakset, grab, fine and so on. So having all those tools. So basically having a Linux deviant that can start with most of the thing being written in rest. So it is really my goals and then I can retire because it's still 20 years of work. But it's fun, as we were discussing earlier, like, you can improve the error messages, and it goes a long way to make the life of the new generation easier. I'm, honestly, I'm, I've not really messed around with it outside a little bit of

used Ubuntu in, like, the latest releases. But I, I'm really, I'm happy that somebody is trying to do something different here, right? I think there's definitely a lot of... How would I say it? There is this idea in the Foss world that everybody can fork something, but how dare you go and do something on your own? There's this idea where people don't like...

Some people don't like the idea of not contributing to the main thing. But at the same time, we'll then talk about, like, you could just go fork anything you want, and that's the power of Foss. So, I don't know, I... I'm happy that someone is like addressing these problems that do exist and trying to create a better project. It's not like the GNU implementation is bad per se. It's just there are problems that are sort of natural to the fact that it is a project written in C.

So I'm, I'm, I will be keeping an eye on the project for me. many, many years to come. Who knows where it's going to go? Because obviously, Ubuntu's adopted it now. I don't imagine Ubuntu's got any plans to leave it behind. So if that's the case, I don't know if, I don't know if, like, Fedora would consider experimenting with or anything else would consider experimenting with it.

I think it's... We're in for some interesting times, that's for sure. I'm waiting for your PR for your contribution. I have done a little bit of rust. Maybe I'll do some more rust and we'll find a best, what is it, good first issue, that's it. Yeah, well, I can send you plenty if you want. Plenty of things to improve.

I also like to arrive that it is not my work, it's a lot of people, like a lot of people who are much better developers than myself. What do you say? Texas Village. I do hope that any sort of transition we do have here It goes smoother than some of the previous Linux transitions That have taken place, you know, like System D or Pulse Audio and then pipewire

Now, Wayland, obviously, is another big one Even though most people have adopted all of the latest thing There's been a lot of, there's a lot of turmoil along the way, that's for sure. Yeah, well, I'm sure that's the same. It has been smoother in Wuntu, but I'm sure in Delian is not going to be smooth rider I think with anything like Debian though like Debian's just been

Debian's just been around for so long right it's second wait so which came first Devin or Slackware? Slackware I think Okay second oldest longest long second longest running distro

yeah that's what I'm saying so any sort of change there is going to there's going to be maintainers who've probably been around for almost that entire life so it's always going to be some long discussions that have to be had in any district like that. Well I think

the approach that I'm going to take in Debian is not to say that we are going to replace one by the other but having the two being installable like what they did in Ubuntu being able to switch between one

implementation to the other even if it is a core piece of the software. This is what you can do also with the compiler. For example, it's very easy to use Kling. Even if TCC is the primary compiler, you have ways to very quickly use Kling on your system if you want to.

So you mentioned a little bit about some of the other places, like some of the companies that have adopted your utils. I guess if you can expand upon any of that, like what are some of the places that

people may not even know they were using it where they can already find it that you at least know of well the the snap glasses and i don't know where a purchase is the name of the linux distra that is designed for cars but i don't know who uses it so i cannot answer i don't know i'm sorry i'm sorry it's like it is one of the of the of the cool and frustrating thing with open source is that you don't know who you uses your stuff. Until they decide to contribute something upstream, you don't really have any idea that like, oh, here's this random product that happens to be using this. Yeah.

Yeah, sometimes you see some people working at company X or company Y and you always wonder, oh, what is using it for? Why is that person is contributing? Maybe it is on their free time. Maybe it's for work. You never know. I think we've pretty much covered everything I wanted to cover. by the looks of it.

Actually, one last big thing. Like, what is the... I actually kind of catched it before when we talked about like the ultimate goal, but like, what is the scope of the project? Like, obviously you have the core utils, you have the fine utils, sad, great, all these different things. Is there

like a point where you want to stop? Is the rust going to spread forever? Uh... My initial goal was to focus on the package that was part of the default devian installation, the minimal one. That was that one, my goal. There are things that are going to be difficult to implement, but I don't want to implement system if it is your question. Fair enough.

It's not that fun. But no, those comments that you use in your terminal all day long, those ones, like all great, said, those cool comments. If people want to contribute some new project and start it, be my guess. I'm happy to take more projects under the umbrella of your utilities. It's just if they need to be relevant and they need to have users when there is no point implementing a tool that nobody uses. They need to be really popular and used by on Linux distra for real. So if System D wants to go and re-implement in Rust, you give him a thumbs up.

that you're not getting involved with that. No, it's true. Maybe a patch here and there if you find something you want to fix, but it's not going to be your project. No, not at all. Well, yeah, I think we've pretty much touched on everything. We could obviously keep going, but I think we've pretty much hit on everything I wanted to hit on.

Is there anything that sort of you wanted to get to that we hadn't yet? No, people, I feel free to contribute. We always have a good first bug. Fixing the last compatibility issue would be nice, but also improving the performances, documentation. This suite, it's always welcome. And also, yeah, plenty of good things to do in Oakh, grab and set, while the rest core details are fully compliant,

or almost fully compliant. Those projects, we still have plenty of good first bug and full feature that we could add. So if you want to get involved on like the ground floor, like Ork is a good place to get involved right now. Yeah,

we just started that project. So you have great maintenance also on that project, good first bag, implementation and plenty of corner cases to manage. Yeah, it's a cool project.

So I learned plenty of things. I'm sure there's going to be some problem that happens when a distra decides to adopt it and then it becomes a, that's going to be the news for the week when some core thing breaks because there's some weird case the orc is doing that has not been

implemented yet yeah yeah that will happen or is like some weird performance issue where if you try to do something with two billion lines of code then it breaks in some weird way of course but at the end if you don't have bugs or if you don't have people complaining about your software it's probably that you don't have users at the end so it's always a pleasure like you know when you have people complaining about your software it's like oh that means that i did i did something that people care about even if it is sometimes negative like i are talking about my cool side projects that i did during covid and uh that's still uh that's still interesting and yeah i prefer that than doing a project without any user of course nobody complains if uh if you are

doing a project without any user it's uh it's always exciting to see that what's a look at it i guess Yeah, yeah. Okay. If people want to keep track of the project, if people want to get involved, where can they head to? So, Utel.org, and we are on Mastodont and on Twitter and on Discord. And again, we have plenty of good first bugs. So just go on GitHub and look for good first issues, I think it is called. And we try to add plenty of those.

Many of them are pretty easy to fix. Okay. Oh, yeah, I see. You do have a tag for that. Sweet, yeah, check those ones out. What's a random one we have here? Sort opens too many files. Oh, yeah.

This one is not easy. Okay, that's the first one I clicked. Okay, maybe not that one. No. Now you have someone full. What is this? Sec 1, this is already closed, SEC 1e minus 922337-2-037-2036-8-5-4.

What is, is that a number that should be important? I don't know. It's probably close to the limit. Oh, okay, okay. You know, when you do an overflow or something like that in Rustin can panic. So, you know, it's all those scenarios that you have to match. If you use argument, X, and this one is close to the max size of U-32, what should be the behavior, should you fail. In that case, you look at what Gnu is doing and you repeat it the behavior.

In some cases, we can extend the precision and we can under bigger numbers than them because it's easier for us. You see that kind of thing. So we have plenty of those weird thing. I click that one trying to find like another good first issue the comment under it says this is not a good first issue as it requires internal as a second big decimal

as a second big decimal there are probably good first issues in there I'm just clicking the ones that happen to not be check out the repo anything else or do you mention all the links that people can go to do you mention the website GitHub Discord? I think we are

easy to find online I just take one for you and you're a good first issue Okay Okay Cool So I guess I do my intro and then we'll sign off Cool

Thanks Okay My main channel is Brody Robertson I do Linux videos there six-ish days a week Sometimes I stream as well I've got the gaming channel Brutio and games Right now I'll be playing

Actually maybe I'm done with MetalGa Solid 3 So I might be on the next MetalGersolid game Check it out. Also, Yakuza, like a dragon. And if you're watching the video version, this, you can find the audio version of basically every podcast, every, every podcast platform at Tech Over T. The video is also on Spotify as well.

Audio, everywhere you can find podcasts, you will find it. How do you want to sign us off? What do you want to say? Thanks for your time. That was great. Absolutely pleasure. I think he's a good first book for you. Oh, oh, you just, uh. It was a fun one for you. Okay.

It, where we're going to, there we go. Um, I opened it in the wrong window. Of course it did, but why didn't it do that? Yeah, if you do a printer with a very large negative number, you get a panic. Which is a nice way to forward to... Okay. I'm waiting for your PR. Okay.

Don't forget to write a test, please. We'll see you're sure. Well, I'm going to go to bed. That's a later problem. Well, to more mornings then. Well, that's good. I guess I'm going to stop the recording now. Because we kind of slip past the outro, but I'm not doing another one, so I'm just going to end like that.

Bye.