Hi. Hello. I hope you had good beers yesterday. Thank you for coming this morning. I'm going
to talk to you about a work that a few of us started a while back, which is implementing
one of the pieces of software that we all have in our computers, so the corridors. So
I will go through the history of that project, explain what we are trying to do, the why,
and maybe do a demo, let's see what happens. So who I am. I'm doing a lot of things, way
too many things according to my partner. I'm a Debian developer for like 15 years, LLVM
for 10 years. I'm also, my actual job is I'm a director at Mozilla. I'm doing 2,000 things
every day. But that work is clearly unrelated to what we are doing at Mozilla. Don't tweet
saying Mozilla is working on that stuff. I will get in trouble. I don't want to get into
troubles. But it's not a Mozilla project. But I have been working with a rest developer
for a long time. I manage some key people in the rest project. And in Paris, we had the
chance to have a bunch of people who worked on the rest for 10 years. So I have been in
touch with those developers for a long time. I also uploaded the initial version of Resi
in Debian a long time ago. And if you don't know about packaging, you can package a software
when you are not an expert in the language it has been written in. I know that sounds
crazy, but I'm not a C++ compiler developer, but I'm maintaining clang for like 10 years
or so. And I'm also maintaining some of the most common rest packages in the Debian archive
for a long time and therefore Ubuntu. But yeah, let's talk about what happened. If you
remember, something weird happened three years ago now. Most of the planet went on lockdown
in our country, sorry, in France. And I think it was the same in Belgium and Italy and some
country. So they decided to close everything. So I don't know what you have done on your
side, but myself, I asked myself, what can I do with that three times that I had? So
some people make bread. So I stole a picture from Julien Donju. He made some fancy bread.
Who did bread here? A few. Cool. Some others did some woodworking. So I stole a picture
from someone who used to work at Red Hat, but now he's working at Mozilla. He did some
woodworking. The picture is ugly. It's not my fault, but some people did that stuff.
Some people did gardening. And myself, what I've done, it's my son on the top right.
He loves Lego, but he's disfiring everything. Everything was put in a single bucket and
we decided to rebuild the Lego. So it kept us busy for like three or four days. And then
we still have to work, but my partner decided to wear 40 something, and she decided to rewatch
Buffy as a vampire slayer. I have a good memory for TV show, so I was like, yeah, I don't
want to watch it again. So, and then she did also that. So you can do the math. It's like
200 and four hours. And basically, I used that time to work on the rest, because she
was watching that stuff and I already saw this episode when I was younger. So yeah, wanted
to learn the rest. So before what I've done, 10 years ago, I worked on that fancy project
which was at the beginning of Clang when it was just starting to support some basic C++.
I packaged it into Debian and then I rebuilt the Debian archive instead of CCC. I used
Clang and coped me a job at Medea at the end, and a lot of fun. I'm still doing that stuff
even if I should stop at some point. So the idea of that project was how can you replace
a compiler by another one? Or like, yeah, I'd like to do the same with the rest. I'm
not a student anymore, so I don't want to do projects that are useless. So I want to
work on something interesting. So I started thinking about what can I do? So the first
one is, do I want to rewrite the GLC in rest? Maybe not. It's probably too hard. So Clang,
Clang, LLVM, it's crazy. There is no way I can do that. And nobody is going to be interested
in those projects. So I was like, what about the corridors? So one of the things of the
corridors is that initially, I didn't know anything about that stuff. So like, oh, it's
probably full of assembly. I don't want to learn assembly. I don't want to read assembly.
But at the end, there is no assembly in coroutils. There is just one file that I never, I don't
care about that one anyway. I'm good. But yeah, some people are going to say, why are
you doing that? It's pointless. So yeah, it makes sense. You can think about that stuff.
But the first one is why not? Like, we all had crazy ideas in our careers and this one
is one of them. Rust is amazing. So you can bring some value and you will hear during
that talk, me repeating that stuff many times. I would like to, I will repeat that stuff
a few times. But the new implementation is fantastic. People doing that work are amazing.
They are giant. And we always hear that Rust is amazing at security. At Mozilla, we keep
repeating that stuff. But for the new implementation, it's not an argument. There are only 17 CVE
for the last 20 years. So it's not about security, the re-implementation. And it's not about
the license. I know that some company cares a lot about license. Myself, as soon as I
can upload it into Debian, I'm fine. But some people love debating how the TPL or MIT are
amazing or the SAC, depending on who you talk to. I am not interested to have that debate.
I leave that debate to Reddit or the other one. And last but not least, it is super
interesting. I hope during that presentation, I will be able to convince you to contribute
and write patches. It's not that hard. I will even do a demo of fixing a bug life, hopefully.
So I keep talking about that stuff. But I think you all have a basic understanding at
least of what are the corridors. So we'll start with a quiz. So who was born before
2000 in that room? I see a lot of gray hair. Oh, yeah, a bunch of people. After 90, who
was born after 90? After 80? After 71? Yeah. So congrats, you are younger than the initial
implementation of the corridors. So the first version was published by Ken Thompson in 70.
So thanks to software age, the archive done by Inria and a lot of actors, you can see
the sources of the initial implementation. As you can see, the.s means assembly. I won't
share any assembly code today, don't worry. But you can look at the source and it's pretty
amazing to see that that code has been written 53 years ago. So Ken Thompson and Denise Richie,
they worked on that stuff a long time ago. And what we are doing right now, and you can
generalize to most of the things in text, is that we are building stuff on the shoulders
of those giants. So those two folks invented things that we are still using on a daily
basis, like we all use CPMV and all that stuff. Even if you don't know about it, your system
is probably going to use it behind. I will also mention that it Postcat is very good
from Adam Gordon-Bel, who is interviewing Brian Kerrigan, talking about the history of
the unique operating system. So those folks wrote a new implementation
of those commands in 72. So you can see that, for example, CPE and the if command were written
in C. The code is surprisingly easy to read. So this one is a source from, again, 50 years
ago of CHMOD. I'm sure that if you know a bit of C, you can read it. And found that
fascinating to see that the code those folks wrote 50 years ago, I'm showing you that first
time in 2023, and it's still relevant, and people can relate to that code. And you can
ask yourself, is your code you are writing today still going to be valuable in 50 years?
Probably not. But those folks, they made it. And it's probably going to stay for a long
time. And this one is the actual implementation of the CHMOD function in the function written
in 72. So it's not crazy code. It's full of bugs, probably. But it worked, and it is
what started Unix a long time ago. And what I found surprising listening to that podcast
is also how amazing programming language, the cori-teals and those command are. We take
that for granted. But when you think about it, when you use sort, unique, cat, and all
that stuff, it allows you to do some crazy things very quickly. So let's take a few seconds
and think, I'll give you a text file, and you want to tell me what is the most common,
the five most common words in the Shakespeare books, longer than six car. We can all do
that stuff. It's probably six, seven lines of Python, same in Rust and same in source
languages. But if you do that in cori-teals with bash, it is that common. And when you
think about it, it's very impressive. That pipe and the redirection are the key things
that we are doing, and how easy it is to program on a daily basis. All your system is running
that kind of stuff on a daily basis, and it makes it super easy. I'm not saying that it
is great. It's not fault-tolerant. If you have the single error in that command, everything
is going to break, and you are not going to get what you want. But still, you can do that
kind of thing very quickly and very easily. So by the way, the results are those ones.
So in Shakespeare, more than five letters, it should further accent. I don't know how
to pronounce that one. So I had to Google what it means. It means that you leave the
scene, or that is what it means in English for Shakespeare before and master. And it's
pretty funny to do that stuff. I did it until eight character, and it's quite interesting
to see what Shakespeare used in terms of words. So now, let's talk about today. My brother
is a story teacher. I'm not. So I will talk about what we have now. So we have 105 commands
in the implementation. In the glue implementation, we are trying to reach that level. You are
very familiar with many of those. Some of them you probably never heard of. And I'd
like also to remind that what is in the corridors can be weird. So sometimes you don't have
fine, you don't have, in the corridors you don't have fine less tops and all those commands,
but you have some other things. And most of these commands, they come up with arguments
which sometimes are conflicting with each other, sometimes are completely changing the
argument of the behavior of the command depending on what you enter. So second quiz. So who
knows about those commands? So L-I-C-P-M-V. Everybody, sure. And then this one, probably
too. Now we are starting with the art stuff. Num format. So it's a command that I, yeah,
there is one of the maintainers of the project with myself. So of course he knows. But really
much it's the only one. So it's the kind of stuff that we have to deal with because we
want to be a drop team replacement for the new project, but we have those kind of things.
And who knows about PR? Yeah, one guy. So someone else. Convert text files for printing. So
it is one of that command and it has a huge number of arguments which are probably conflicting
with each other. So C-split, who knows about C-split? Daniel knows. Yeah, just a few people
in that room. So it is to split a file into sections determined by the context line. Yeah,
it's scripting, right? Yeah, it's weird. And we have plenty of other. So we have factors
to do math. We have Pinky. I don't remember what he's doing. T-Sort is doing some kind
of search. Shred is to delete, really remove the data of a file on the drive. I think it's
more common, but still I rarely see that one in scripts. And so we have a bunch of implementation
of the curators available on the market. So the most common that everybody knows is a new
implementation. There are BSD, which is used on Mac, for example. BZbox is the one when
you want to use on MBD devices or when you want to recover a system. Toybox is one of
the core developers of BZbox. Decided to rewrite Toybox because it was sick of license
discussion. I learned recently that there is a VLAN implementation. Don't ask me what
is VLAN. I don't know. And if you are aware of the implementation, please let me know.
I will tell you why I want to know. So let's talk about our implementation. So it was started
by Jordy. I will butcher his name, but Bushiano in 2013. Before version 1.0, I sent an email
to Jordy because he has a.be email addressing. I'm going to present the work that you started
10 years ago and he said, cool, glad to hear that this project is still alive. Myself,
I found it in early 2020, before COVID, and then I started contributing in April. Remember
that COVID started in Europe in March. It's not a coincidence. Now, he reads the size of
the project. So we have 13,000 stars and we have 350 contributors. The second contributor
to that project, you see his picture with a white background is over there. Well done,
Terz, for your amazing work. He's the one reviewing RPR. I'm doing the easy one. I'm
not a very good developer in general. Now, it's packaged in most of the distro. Obviously,
it's not a coincidence in Debian and Ubuntu, but Fedora, Gen2, and most of them. It's used
by it is shipping in Apertis, which is a Linux distro for cars, which between you and me,
from that scary, that they are using our work in production. But I'm always the imposterous
syndrome in terms of development. And it's used by a social network through the Yachter
project. So it's not Facebook, the famous social networks, another one, and they are
making glasses and so on. So I think you can guess who they are. But they are using that
to take pictures in the glasses. And this one is for license reasons. So now I'm doing
some product placement for one of the Mozilla achievement rest. So why do we want to do
it in rest? It's, you don't have to worry about security issue at Mozilla on Firefox
in particular. We see security issue caused by C and C++, not on a daily basis, but almost.
And you should not do C and C++ anymore if you care about security. It's very portable.
One of the things that I learned with that project is we are supporting a lot of configuration,
a lot of operating system. And rest is really amazing for that. It was one of my big discovery.
So views probably for some of the rest developer in the room. But for me, it was a surprise.
And I really don't like to invent the wheel. So we can leverage a lot of great which has
been developed by very talented people over the years. So LS color, for example, is used
by LSD or XR probably to provide the same color as LS. And we are using that stuff in
the rest corridors. Worked here to do a recursive operation on the directory. We are using that
crate so we don't have to worry about that one. Temfile, we use it for MKTem, for example.
So if you look at the sources of the node corridors, they have to implement everything
by themselves. Sometimes they use that in some libraries, but they have to rewrite a
lot of things. While for us, we can reuse what others have been doing. And last but
not least, we have amazing performances. I will do a demo later of some of the performances
that we have. But surprisingly, we are in some cases, we are significantly faster than
the glue implementation. And it's a very popular language. No need to explain why, but we have
a lot of contributors. And sometimes we are struggling to keep up with a number of requests
just because everybody wants to learn Rust. And you should if you don't. But it's very
popular. So what is the goal of this specific implementation? So when I took over that project
a few years ago, I had exactly the same idea in mind as Chris Latner and Apple did back
then with Clang is to be a drop-in replacement. So if you are not aware of that story, when
Apple decided to work on Clang, one of their goals is to be a pure drop-in replacement
for GCC in general for most of the options. And it has been one of the success you just
had to overwrite the CC or CXX variable and you could use Clang directly. And if it was
not working, it was a bug for most of the cases. So it works surprisingly well. Now
Clang is a de facto standard for compiling most of the very complex applications like
Chrome or Firefox. What can we do to replicate that? So the security is we focused on that
one to be a drop-in replacement. We want that stuff to be cross-platform. It has been decided
before my time as the leader of the project, but I love the idea. So we support the operating
system. We are struggling with a free BSD, a CI because it sucks on GitHub. But besides
that, it's working pretty well. Also, except for Fushia, we have CI for every one of them.
So for every PR, we run a lot of tests on those. It's very easy to test. So on my laptop,
running the full test suite takes less than a minute. And it's covering a lot of part
of the code. I will share some of the code coverage information. I don't care about it.
Some people do. For some people, it's a strength. For some people, it's a weakness. But it's
an MIT license so that social network can reuse our code to save money. Anyway, I'm
not interested in having that debate. And in my opinion, and I haven't seen anyone in
the community using that argument, it's not a fight against the GNU project or the FSF.
The GNU project has been doing a lot of good things for us in the open source world for
20 or 30 years. We are standing on their shoulder. It's not a fight. I know that some GNU
quality developer of monitoring that project for a long time have been very friendly and
so on. And I met Tim Mayoring 10 years or 20 years ago. And I was very impressed by that
person. So, yeah, it's not about fighting. It's about collaboration. So when I started
that project two or three years ago, my initial goal where I want to be able to boot a Debian
on it, so my laptop here is running the GNU curricules now. For example, so it's not lying
or it's working well now. Then it was to install the top 1,000 packages in Debian. So if I
wanted to do that, is that Debian has a lot of script to configure the package because
it's post-inst and they are usually done in bash and using the sort and Cp and MV and install.
It's exercising a lot of features of the GNU corretails. And one of the goals was also to
build three of the big projects I care about. So Linux, LLVM and Firefox, obviously. So we
don't use that much scripting, so bash or corretails, but I still found some bugs, building
so Linux can know some corner cases. And of course, package it into Debian and Ubuntu.
I published some blog about it. They have been shared on a bunch of places. I've had
some interesting comments, some of them not very interesting. Anyway, so to achieve those
goals, we had to deploy a CI, add code coverage support, improve the code coverage. So it's
one of the things to get familiar with a project. I wrote a lot of unit tests. So now the code
coverage of our implementation is 80%. If you don't know much about code coverage, 80%
is usually what we are trying to achieve in a project. It means that the code coverage
is very good. It's very hard to reach 100% and sometimes it's a waste of time, but 80
is usually considered as being a very good code coverage. I think on Firefox, we are
at 65 or 70, something like that. And we plug the bunch of tools. I mean, Lov is static
analysis, LinkedIn, so of course I had to do that for that project. And we also documented
a lot of those processes. Everybody loves about docs, so we wrote plenty of docs. And
it took about a year to reach that state. So now the current stages. So what we have
here is CI that is running for every PR. And we run our implementation against the new
test suite. This is the latest graph so you can see that we have been working a lot on
improving the compatibility. We are not there yet. I will fix one of them with you later
during that presentation. But there is no silver bullet. For many of those, you have
to spend a few hours to fix one. And you improve one by one. Before you ask a question, the
skip is mostly that it is AC Linux. So CPMV and some common or CH-con, they are using
AC Linux and GitHub action uses Ubuntu and Ubuntu doesn't have like default, so it's
tricky to test that stuff into the CI. If you know how to do it, please reach out to
us and like to fix that stuff. So how do we work? As I said many times, we want that stuff
to be a timely replacement. So we wrote a mini wrapper to make it super easy. So that's
command that I share is going to run the not-owner test for the touch command on GNU. So it's
going to use the GNU test and run it against our implementation. So it's super easy to
test. And we wrote some script to make our life easier. So we have a Python script which
is going to tell us to the list. If you do it, it's several pages because we still have
a lot of tests to fix. And we wrote also a fancy page. I can show you what it looks like.
So here it is. We have the list of all the tests for each command. And of course, the
big one is MISC where we have a mix. So sometimes it's just one line change in the code. Sometimes
it's a big refactor. It depends. It's part of the fun. You never know what you are going
to get. So let's use an example, for example, for MKgear. So this is the GNU I would put.
So you do dash P. Who knows what is dash P in that one? Okay, cool. So it's create a
recursive and V is verbose. Everybody knows that. So in the GNU implementations, they
decided to do it directly by directly. You can argue that maybe it's not a good use. It's
not smart. Maybe it is. Who cares? It's legacy. We have to deal with legacy. So our implementation
was that one. So you can argue that maybe ours was better or worse. Who cares? But we
updated that code. So we match exactly what GNU is doing. So if you look, I will share
the slide after. You can look at the change. It's pretty easy to understand. This one is
one of my favorite. So in Debian, when you install LibOffice, it is using app or more.
And someone decided that instead of doing a touch, you do install DevNule, which creates
an empty file. It's legacy also. We want to fix legacy everywhere. Probably not. So it
was one of my favorite bugs. So I started investigating. So you use some REST codes
which reproduce that issue. So if you do a copy of DevNule into a text file, it is failing
with a source pass. It's not an existing regular file. So I open a bug upstream. So thread
is quite interesting. Like people in the REST community are very passionate about that
kind of thing. Too long didn't read. It hasn't been fixed. So here is a workaround. It's
ugly. But if you know a better way to do it, besides fixing REST and dealing with a fallout
of the fix, this is the best that we have. So we are looking if the input is DevNule.
If it is DevNule, we are creating an empty file. This is what it takes to deal with legacy.
So let's do a demo together. So please bear with me. It's going to be fun with the mic.
It's going to be fun with the mic. Hello. So, ah, uppercase. Sure. Ah crap. Just switch
to alacrity and never remember the shortcut to increase the font. Ha ha. This one. Better.
Cool. So this is not the new version that I'm running. You can see I'm running our implementation.
So we are working third release 0.0 17 weeks ago, something like that one week ago. So
we are using that implementation of it. So when I took the train to come here, I looked
at the test suite and I tried to find a cool bug for the demo. So I found one and I want
to show you what it is. Because I don't always remember the command because I'm a font of
a crowd. I don't want to look stupid. So I did a post bet within French. So here is building
some stuff. So what I'm testing right now is a sort command. The sort command has some
fancy flag. So this is a command from the GNU project. So I will show you what the test
looks like on the GNU side. So here is the test. So of course we have the TPL3 on top
and then there is a list of file with version name. So we have on the top we have the input.
So for in and below we have the expected one. So the command that they are testing is a
stable sort with a sort by version. So sort and same for LS. So you can specify what kind
of sort you want. And of course doing sort of version is super complex and we can base
it about that stuff for hours. I love it. So here is what they are testing. So of course
as you can see it failed on our side. And why did it fail? So it seems that it is complaining
that 5.4.0 it's not sorted the same way as 5.0.4. Super interesting, isn't it, right?
So basically it means that we are sorting that version differently. Of course it's so
obvious that it is the same version and it should be equal but when you are sorting in
those cases equal doesn't mean anything so you need to make a decision. And of course
we decided to do otherwise because I think the person who did the implementation didn't
realize that GNU was doing something different. So let's try to fix that together. So what
I like to do, I don't know how other contributors are doing is that I like to have test cases.
So what I'm doing is I'm creating some basic command to be able to reproduce that easily
so that I don't have to run the test. So I spare you the details. So here is the test
case. Let me do that right now. So I've got my test file. So what I'm doing is I'm forcing
the full pass to use the GNU implementation. I used the two arguments that we mentioned
earlier and now I have the input and the output. In theory if I do a diff it should be empty.
And it is. I love when demo works well. It's just the beginning so I will probably affect
about some point. So now I want to test the GNU implementation. So here it is. So now
I have a simple test case that I can work on. So I don't have to run the test suite.
I don't have to do anything else. It's one of the things that I love with that project
and that's why I'm not doing REST code at medias because I'm not a very good developer
and Firefox is super complex and that stuff is pretty easy to do. You can do that on the
train to come here. For example, what I need is taking this one. It's probably going to
take 20 minutes to fix. Well, there is a weird thing at the end but I'm not going to produce
a surprise yet. Anyway, this is the code that I have. So let's dive in now into the actual
code. So let's use GDB. So GDB and REST works very well. So if I do a run, yeah, it works.
If I do a breakpoint on main, yeah, it works. Next, next, next. Here it is. You can see
the REST code. You can evaluate the variables working super well. So I won't open and look
for the function. I already did that for you. So I already know the function where to put
the breakpoint. So it's version underscore CMP. Our code is pretty well written. So I
guess you'll understand what version CMP is doing. It's comparing version. So now I continue
the execution and then I'm in the function doing it. So if I look at A, I see that it
is that string. So the first one, if I look at B, here it is. So I have the two strings.
So I will move in quick mode. There is the execution. So we have the version compare.
And here is a function that I care about. So I will scroll. But you see in that function,
it's probably what I care about. Because it is, if you don't know about REST, it is going
to trim the zero at the beginning. So obviously in that case, it is what I'm looking for.
So I want to remove the zero at first. So let's fix that code now. I learned from one
of my colleagues at NANO. So I'm following the example. Yeah, exactly. It's the best,
right? So here it is. I removed the trim. Of course, it's going to break something else
after. I'm confident that it works. So let's rebuild that stuff. So here it is. It's rebuilding.
It is what the file that I touched is using. It's a UCOR. So it's one of our basic library
to do file management and so on. So it's normal that it is rebuilding the values dependencies.
Not GDB. I want without GDB. Please. That one. And did it work? Yeah, it worked. Cool.
I fixed the bug. So very proud of myself. I love how geeks love versioning comparison.
So now the funny story is, of course, because it would be too easy. Now I'm not going to
run the full test suite even if it takes less than a minute, but I'm just going to run that
test because I know that that one fails. So LS has the same function, but LS has a different
expectation in terms of version sorting. So, of course, that test is going to fail because
LS likes the zero before instead of the other one. So, of course, that test fails. So one
of the things that we could do is in the version compare, we could have, do we want zero to
be first or do we want zero to be after doing a boolean? And when I say this, because I don't
like the version comparison function, it's on our tree. So I think it's done. Someone
else did it. Of course, there is a great doing it. So I reached out to the developer saying,
can you add an option to change the sort when it is a zero? So the upstream made fun of
me, but they have a PR ready, so they will probably end it. So we are going to remove
100 offline of code and use that crate because it is what we want to do. We don't want to
maintain a comparison of version because who cares, right? So let's come back to the
presentation. So performances. Benchmarking performance is hard. I know that in the room
we have some experts in performances and they are not going to contract with me that when
I say that benching is hard. But we are using hyperfine. We can see that, for example, the
start is almost five times faster than the boolean implementation because some people
spend a lot of time improving it in our code, but also in the crate. So that one is basically
taking all Shakespeare books, the text file, making it random and sort it. So we are significantly
faster than the new implementation. Similarly, if you do a recursive LS or a recursive CP,
we are 1.5 faster than new is probably because the code generated by RC is much better than
the one and returned by GNU for a long time. But I don't want to pretend that we are always
doing better. For example, with the factor function, we are significantly slower than
the new implementation five times. I don't know who uses the comment factor. I learned
about that comment when I started contributing, but still, we want to be a good replacement
and that one is very slow. So I'm going to do another demo using, I'm going to do some
product placement for a project called Sempli. He is the author of that project. He is in
the room, so if you need anything, don't blame me, blame him. I will do a quick demo
about how can you do a proper benchmarking of performances. I will try to find how to
do the primary perf kernel change. That one. I love the SH. So I just did a recursive LS
with a comment called Sempli. So basically, it is going to instrument it and it's going
to upload into the Firefox profiler, the analysis of that program. So I will zoom in
a second. So here it is. I think Bodhiya did four presentations of the profiler today,
so if you haven't seen any, I'm going to do a quick demo. Anyway, it is one of the magic
things of Rust is that we can easily do that stuff. You saw how long it took. I will show
you the command again that I run. This is that one. So Sempli records the binary and
the argument. So it's very easy. If I try to do that, we see another language is going
to take forever, but Rust and Sempli makes that so easy. So here I have the flame graph.
So I can see that for a recursive LS, most of the time that we are spending is in display
grid. So most of the time that LS is going to spend is not reading at the file or reading
the metadata. It's just doing computation about how do you want to show the result
into the terminal. And one of the amazing things is that it's going to, I can look at
the source directly and see the counters and I can easily benchmark that stuff. So if you
are into performances in Rust, you can use Sempli and the Firefox profiler to do it.
And again, not here as Bodhiya, but it's very valuable for any project. It's not Bodhiya
related and it makes that stuff super easy. So we have also some fancy documentation.
Tert in the room did most of the work. So one of the things that he did that I love
is that one of the things that I really struggled at first when I became a UNIX developer like
20 years ago is that I never knew how to do an example and find the example. So Tert linked
to TLDR.sh where it's providing example for every comment. So for example, here it's
base 64. You have example, but I'm going to use a comment that I didn't know about, shred.
You have example for shred. So you don't have to Google on Stack Overflow how to do that
stuff. You have that out of the box in our documentation. So we have development documentation.
I want good suite for a matter of time. But one of the things, we are taking the liberty
also to extend the new clarity. So we don't want to break compatibility, but we are doing
some fancy thing like progress bar because who doesn't love progress bar? So for example,
of course, it is that one. So we have a fancy progress bar now. You don't have that upstream.
So you can think the guy is over there. I haven't done anything. But before the talk,
he came to me and said, I looked at the implementation, at the patch that wasn't merging new and that
patch was very hard to understand. If you look at the diff on the rest side, even if
you don't know about rest, you will understand it because we are relying on a crate. I think
the upstream developer of the crate is for them also. So thank you for your hard work.
So here is what kind of stuff we can do. We can do it for MV. And MV is interesting because
if you are moving between one file system to the other, it's not always super fast.
We are also implementing some tools that new doesn't have. So B3Sum, for example, because
it's like B2Sum, so it's a hash algorithm. And cut-w, someone contributed that patch
recently. It's one of the options from BSD that new doesn't have. So what is next? We
want to implement the missing option for the values binary. It's not hard. It's fun. We
try to be nice. I'm not always nice, but I try to. We want to have a full compatibility
with new. So the list that I show you, I like that to be fully green at some point. It's
going to take years, but it's fun. It proves the performances on some key programs, like
for example, for Factor. I don't know if we want to spend too much time, but there are
other things where we could improve the performances. And if you're interested, that link is the
most interesting one, to know where to start. It's well documented. We, if you are a student,
we are probably going to apply for the Google Summer of Code. And if someone is interested
in sponsoring that project, if your company or your foundation is interesting, I'd like
to buy some credits on GitHub Action to build faster, because we're running the new street
test about an hour. And I think we are using a lot of resources, so it would be nice to
have a faster CI. And now I'd like to predict the future. So the Linux kernel, they landed
the first support of Rust inside the tree. So if you do some stat on the Linux Git repo,
you see that they are first. So there is only 37 files upstream. It's mostly glue. So how
do you manage memory and compatibility with the system and support for the build system?
We hope that they are going to land something in mainline soon, a feature, but is it going
to happen this year or not? We don't know. And some people are still challenging Rust
in the Linux kernel. The main argument that I heard is mainly for legacy system. But my
prediction is that next year, we will start to see more and more distro vendor or cloud
company to ship with some more and more Rust code. Probably my prediction is that some Linux
distro are going to ship in the cloud our implementation in the next few years. So thanks
for your time. I'd like to remind that it is not a Mozilla project, so please don't say
Mozilla works on that. It will make my life easier. And I think we have a few minutes
for questions.
Here, I think we need to, in the back. We David.
It's an issue for every Rust project currently. The fact that cargo is amazing at updating
dependency is many of the Rust projects are subject to supply chain attack lately. And
we are no exception. So I can do product placement if you, Mozilla has developed a tool called
the cargo vet, which mitigates that stuff, but it's too complex to deploy for a hobby
like this one. So yeah, you can do supply chain attack in our project. But we don't merge
the dependable pull request immediately. We are trying to mitigate that by taking our
time. Any other question? Yeah, two over there. Yeah, please.
The code size compared to busy box, I don't know. With GNU, it's similar. So you have
different way to compile the project. So the trick that I'm using in Debian for the package
is that I'm building a single binary and I'm doing sim link. So if you do a sim link from
curateals to a CP or to NS, the binary is going to understand that you are calling CP.
So the size is comparable to the new implementation in that case. But because of the nature of
course, the binaries are bigger than the rest. Another question? Yeah, it's a question that
comes back so often. Do you compute the code coverage only on the passing tests or all
of them? We run code coverage on everything, including the GNU test suite. So it takes
an hour and a half. So the tests that are failing? Yeah, yeah. We test everything.
Did you find any bugs in the original GNU implementation when doing the re-implementation?
Yeah. We have a contributor who found two or three bugs in the upstream implementation
and they have been fixed up. We ported and fixed up. Have you had any need to use unsafe
and if yes, can you give a few examples in which kind of areas? We have some unsafe when
we are calling the libc, some function of the libc we are calling it directly. So we have
some unsafe. Yeah. I'm going to repeat what he said. He said that it's for the libc. It's
mostly native calls. Have you looked at code complexity metrics like
cyclomatic complexity? Because I guess with the error handling, the memory management
and cleanup in C is often really messy and that could be a huge boon in maintainability.
Yeah, yeah. We have some codes that clearly need to be factoring. So for example, in LS
we have to work around the limitation of CLAP and the code complexity here is getting more
and more complex. Yeah. That project needs some policies of our implementation need to
be factoring to decrease it. But the code is usually pretty easy to understand. Thanks.
Okay. I think we're out of time. Thank you all. Don't hesitate to contribute. I can find
an email if you need.