So, I'm going to quickly introduce myself, so I've been a deviant developer for more than 20 years, which gives you an idea of what my age.
And my work, while I'm getting paid to do, is to, I'm a director at Muzia for, sorry, Muzia.
Do you use the Ecoso? No, it's good, better. Cool, thanks.
So, my page job is to work at Muzia, and this work is completely related. It's not a Muzia project, it's not supported by Muzia in any way.
It is one of my side projects that I'm doing in the evening and doing the weekend.
I have been involved in the rest community for a long time. I uploaded the first version in Debian while back, and it's now in the Buntu.
And I've been a maintainer of some key packages in Debian and the Buntu based on the rest for a while.
So, here is what I'm going to talk about. First, I will ask you some questions.
Then I will present what we have been doing with the implementation of the core deals in rest.
I will do a demo, and then I will make a proposition to the open source community.
So, first, I'm going to ask you some questions.
So, who are here in the room as pung opinion about the CPL, and especially the BSD and MIT?
So, for the recording, it's about like one third of the room, one quarter.
Myself, I don't care, as long as it is open source in the OSI and FSF definition, I'm completely fine.
The project is not about license, even if I'm going to talk a few times about licenses.
Who asked for the opinion about the new project? Not that I'm saying the new project, not the FSF.
So, I see only a few hands. Same. I still contribute to a few new projects like career deals or GCC, also kind of things.
So, Miguel did a talk right before about the Linux kernel and we're writing some part of that in C.
So, now the question is, who asked for the opinion about C? Yeah, a lot more people.
Yeah, yeah. I really don't like C. I think it's going to die, and at some point I think our kids are going to put C in the same category as Fortran and Cobalt.
I think it's time to move on, and this is why we need to start that work now.
And who asked for the opinion about first, positive?
Yeah, many people call. So, you're in the right room.
So, now what I'm going to tell you is this quick story.
So, it has been five years that we all had to go in lockdown. So, it was 60 for everyone.
And some of us, we made some bread, some people, the guy on the right, he was in the LL Ventura.
He did some woodworking, some crazy stuff in with wood.
Myself, I, with my son, we started building also, they go in the boxes.
So, you can see Wally and some Star Wars and some Batman stuff.
But I needed a project in the evening. So, I was like, I want to learn the rest.
West is a material project. I have been surrounded by upstream rest developer,
inside the Paris office of Maria, some several developers.
So, I want to learn it myself, but I'm not a student anymore, and I don't want to do a site project
that it is going to be just sitting on my otherwise. So, I want to do something impactful.
So, I was thinking, what about implementing the corridors in the rest?
Especially, I was curious to know how it was working. I saw it was full of assembly.
But actually, it's a very simple scene most of the time.
And I was very inspired, I've been contributing to LL Ventura, LL Ventura,
for like 15 years, and I was very interested in inspired by the works at Chris Latner.
That Apple, one of the core fundamental of Clang, is if you have different behaviors and CC, it is a bug.
And I was also involved in that project with my debut an hour, a long time ago.
I started with building the debut an archive with Clang, and I reported plenty of bugs upstream,
and I fixed some of those. One of my favorite is this one.
So, some people saw that if you put a dash or six in CC or Clang,
it's going to optimize more than all three or all four.
We even held in the debut and could base a dash on 99.
Someone saw that it would be way more optimized than three.
Of course, it doesn't change anything.
Now, one more question, who knows, in that list of corridors program, who knows one of them?
Well, almost everybody, who knows five of them?
I have a few. Who knows everything here, in that list?
I'm pretty sure nobody, except if there is a new upstream developer, one of my favorite is PR.
Who in the room knows what PR is about? You always have that on your system.
If you are running Linux, I see one guy over there.
It's basically to format the text for printing, actual printing on the printer, like paper and so on.
Some of the comments here are not very useful or used anymore.
They are legacy, but for compatibility reasons, they are still over there.
You're all familiar with those. Like, I selected those offensive ones, or CH-mode, CH-roll, install, and so on.
L-S, M-Cardier.
This is a comment that you folks, if you are running a Mac or Linux, you use those almost every day for your work.
So, it is a full list, 105 comments.
So, now it's, we are five years later, after COVID, five years later of working on that project.
As you can see, I have way more gray hairs than I had five years ago.
We have in the project, this is a screenshot from last week. We have 530 contributors.
How many projects has that number of contributors? Not that many.
We have more than thousands, we have right folks.
And we have almost 18,000 star on GitHub. I know that it is meaningless, but still it's one of the metrics that we have.
And I'm very proud to show that this is a graph of when we run our implementation in Rust.
Again, the C test suite, the C-based state suite with new.
And as you can see, we started, we had 139 only test passes when we started the project in 2020.
And now, we are almost 500. I should have worked as weekend to be at 500, but I didn't have the time.
We are very close to a full completion of the project.
And most of the tests that are failing right now, some of them are in PR and some comments that nobody cares about.
Or sometime we have some weird, I will put ordering.
So, if you delete, if you use RM on the directly and you don't have permission,
new is going to show something first and we show it at the end, so it's going to make a small difference.
So, what we are also doing is we run the test independently.
So, we have that fancy dashboard, which is telling us that, for example, with Scott,
we have one test that is failing currently from the new test suite, but C-H group and the C-H zone and C-H roots,
there are fully compliant with the new test suite.
That doesn't mean that it is fully compliant because it is the new test suite as a limitation.
So, we are contributing upstream to the new project when we see some stuff that are not tested.
But that shows that you can use it in, you have, you can trust the code.
You can trust that it is working well.
And it's, you can also verify that you are not progressing when you are making some changes.
So, the current status, I'm very proud to say that we are production ready.
We support Linux, Mac, Windows, Android, open base day, freebie, SD in at BSD.
If you use Fushia Redox, then Wazam.
So, it's most of those target are in the CI, not all of them because GitHub doesn't provide everything here,
but we have a lot of good coverage.
It is also now used in production.
Most important thing on my laptop, this laptop is running that implementation.
So, it is a kind of production, but we have also,
a collaborator who worked on that project to ship it on an apartment.
So, if you have an apartment's version, it's going to have our implementation.
If you are in, if you are young, you might know about Snapchat and spectacles, the glasses,
they are running our implementation.
I must admit that those two are mostly for licensed reason, but it's working well.
There are certain production.
Microsoft is also using it for VS code web.
It's a lot of article about it because it is written in the rest,
compiling the rest to web assembly, it's pretty easy.
And it is one of the beauty of open source.
It's probably elsewhere, and if you use that in your company,
and you didn't tell me before, please let me know.
I'm always excited to know when people are using our code.
And it's almost all Linux distro.
Some of them, at least one, that I know,
the third point to us is now shipping by default with that implementation.
So, before that took me well already covered some part,
but here is my point of view of why it works.
Why it works for this?
We have, we are seeing that rest is replacing C and C++, almost everywhere.
So, I'm completely biased. I work on Firefox.
It has been my work for 11 years and 10 days.
So, I was part of the release management team,
when we started shipping rest in two Firefox.
I'm completely biased on the browser part.
We know that Chrome is also following our leading database,
a Linux kernel and menu operating system.
We know that Microsoft is using it for Windows.
Going to study reviews, but rest is very good for security,
for parallelism, for performances.
And I'm going to show you that in the demo.
But I like also to say that we are not replacing the simple implementation,
because they did a poor job in terms of security.
They did an amazing job.
They almost don't have any security issues in their codebase,
they are doing amazing work, and it's super safe.
So, they're not about being better in terms of security.
As I'm playing several times before, it's not about license.
I'm not interested, I know that some people care a lot,
but it's not why I'm doing it.
Second part. It's very portable.
Some people are surprised when I say that.
Unlike Java, it's really really portable.
So, I mean that if I write a code,
usually I'm almost certain that it is going to work well on Windows and Mac,
and Android, which is very surprising to me,
given the complexity of everything that we do,
and everything is platform-specific,
but things to the ecosystem and things to the quality of rest.
The cost of parting a change to an operating system is very, very small.
And I know that one is up to debate.
Myself, I'm on the side of AMAZE,
so if there is a great doing library doing that work,
I'm going to use it, I'm not going to implement it.
We have like 200 dependencies in the rest of our materials,
because we don't want to be implementing.
I do understand that there is always a supply chain attack risk,
but it's a risk that we are willing to take,
and they are more and more tooling around that to protect ourselves.
And if you did some Windows Mac and Linux development,
in your career, you know that parting new dependency on a different,
another operating system is a nightmare.
And the rest is usually as easy as typing,
cargo, add, and the name of the crate.
Usually everything is managed by for you by the build system.
I'm a developer and I'm a geek,
it's also super interesting to learn a language.
Like it's part of what makes our job super exciting,
is learning new things every day.
And as I'm getting older,
I'm my son is ten years old.
I also think about what we are going to live to the new generation.
There's a new generation.
They don't want to do cobalt, see, or for twins.
They want to do fancy stuff.
Like rest, we have to go or cut in.
And I think it's a good investment for the future
to start now investing in the new technology and the new languages.
And the new approach for the future of the Linux ecosystem.
And the computer science system ecosystem in general.
Now I'm going to do a demo.
I'm going to do some product placement for some of the cool stuff
that we do at Medziab because everything is intertwined.
And if I know about those tools also because I work at Medziab
with the folks who develop those things.
So please bear with me.
It's a demo.
It's never perfect.
And I need my notes.
Here we are.
So yeah, we can see cool.
So I'm using Alacrity Terminal Invest.
And so point is Starship also Invest.
So most of the tools that I'm using on Medziab.
I'm packaging the Medziab and they are almost all I have to do
the box with some customization to make them nicer.
So you all recognize the pattern.
So I've got a cargo.tml.
So what I want to do is to show you, for example,
that I'm using the best implementation of that.
And if you are from Australia, you will appreciate
an opportunity that we are telling news
that you are spelling color wrong.
Color should be spelled this way.
But we are helping you to fix your English to write way.
So what I want to do now is to show you one of the,
so we take the liberty at times to, to different
I was self on the new implementation.
So what I'm going to do is we added a command, an argument called dash dash progress,
where you have the progress bars.
And if you have been using CP, you don't have that.
And it can be very frustrating because you never know how much time it takes.
I have not done the implementation.
It's one of the other maintenance, third, third of the clubs.
And it's pretty easy to add that.
And if you see other places where we could add it, don't hesitate to let us know.
We have also some algorithms that we are shipping.
No, it's sorry.
The demo effect that I said.
So we are also, for example, we have that as algorithms that we are shipping.
Of course, it's totally because it's waiting for something
on the city in.
But we are also taking the liberty to add more stuff.
So what I want to show you also now is how easy it is to run test.
So the command, cargo test.
Sorry, I'm going to clear the screen, capabilities, cargo test.
We all know how it works.
We have dash dash feature.
We say I'm running a unix.
Because we have also unix dash SE Linux.
I'm a debyan user.
So I don't have any CD news and I don't care.
But some people care.
So we have also instead of unix.
We have Linux, underscore SE Linux or something.
And here I want to run only the test on sort.
So I'm building the dependency.
It's going to take a bit of time.
It's not in with this.
So here it is.
I launch all the tests.
And as you saw, it only took one second.
And, sorry, one second.
And one point two seven second.
To run the test suite for all sorts come in.
If I were doing that with a new, it would take 20 seconds.
Something like that.
And it's much harder.
So it's very easy when you want to test your changes.
Because you can quickly on the events,
or test on the commands that you're attaching.
So this is easy as this stuff.
So what I want to show you now, it's my laptop falls.
Of course, it's a demo.
Let's move to a different terminal.
You can see, yeah, perfect.
So, ah, it's probably because I have something mounted.
So it's why it's long.
So on my system, I'm basically to run my implementation.
I'm just avoiding the pass.
So if I'm typing the full pass to the implement,
I have a full increment.
So you can see here that I'm running not the latest version.
I'm using the package one in Debian.
In Debian, we still have the 9.5, which is not the latest,
which is important because they improve some performances.
Anyway, ah, I have on my system,
ah, all the books that Maria wrote.
But because I speak in English,
I'm going to use six years, an example.
So I'm using a W-L and we can see that we have all six
year books about 127,000 lines.
So now what I want to do is to do some benchmarking.
So I'm using hyperfine, which is a worse program.
One more to do some easy benchmarking between a command line program.
So let me type it from start.
Debug, corality, sort, Shakespeare.
Of course, I need quotes.
And now I'm going to give the signal.
So if you know about stress, you are telling to yourself,
that guy on stage is stupid.
He doesn't know what he's doing.
He's using the Debug build of stress, which is often very slow.
But it's part of the demo effect, right?
So I'm running.
So what if you're fine is doing is running 10 times the program.
And as you can see here, that part, you have the result.
And we can see that even have our Debug build of sort.
So sorting all the line in Shakespeare books is 1.45 times faster
than the new implementation.
It's because we are using some rest week and work makes that super easy.
So now because it takes forever, I already build with this bug.
A village build of that.
So instead of doing Debug, I'm just going to use a village build.
It takes a few seconds.
And we can see that we are six time faster than the new implementation.
So now it is when I start doing project placements from the staff.
So I'm going to use a tool that one of our colleagues developed,
called simply, if you are into profiling performances, you should know
but simply, if you don't, you are making a mistake.
So what I'm going to do is I'm going to ask simply to do a profiling of the sort itself.
So activities, it's analyzing.
Now I'm going to go in Firefox and I'm going to open the Firefox profiler.
It's one of the things that we developed to improve the performances of Firefox.
So we can, I'm not going to go into many details about the few,
but we can see the performances, we can see the values thread.
And what I like is graphic or flam, flam, whatever in English.
And so I'm going to do, I'm going to look at the profile.
Of course, I prepared everything before.
So I know what I want.
But we can see that here, I'm spending 30, 29% of the time,
just to do a resize of the vector.
And if you went to university and studied that,
it's one of the basics exercise.
So why are we spending that long on that stuff?
So I can double-click because of the res magic.
I have access immediately to the source code.
I'm not here to do a demo of the profiler.
I'm going to do one more product placement.
Some of my colleagues are going to present certain the web
perform later today.
But I can see that here, I'm spending most of the time in buffery size.
And I'm like, oh, yeah, it's probably not the right thing to do.
So I'm going to go back to the terminal.
Just to show you Shakespeare.
Here it is.
The end of the bottom.
The end of the last book.
So what I want to do is I'm going to do a backup first of,
so that we don't have to be compile.
Of the debug bills, target the bug, corretiles,
previews for first-dem demo.
So it's super clear.
And now I'm going to show you one of the patch.
It's certainly, I don't want to put it in the tree,
because I don't like and say it, but it's one of the tricks
that you use to do an initialized memory.
There isn't any safe at the bottom.
So it's not some things that we are going to influence
our better ways to do that in the rest.
But it's just for the demo.
So what I'm going to do now is to apply the patch.
I'm going to do a rebuild again.
Well, I will show you how quickly this to run the test.
So I'm running the test to make sure that I don't request.
I didn't request the test.
Cool.
And now what I want to do is to run sample again with a new cut.
So I'm opening the profile again.
Graphic of Flammer Core.
And here it is.
We see that the sort, the weak to buffer now,
is we present only 5% of the time.
Now what I want to do is to do some profiling of that.
So my laptop is not plugged.
So on the power, so it takes about 2 minutes to do a rebuild
of an in-release.
It takes 1 minute when it is plugged.
So I will not, we are not going to wake
together for 2 minutes for the compiler to finish the job.
So I already prepared the build.
So I'm going to run hyperfine.
And now what I want to know is,
I don't have completion in that case.
Let's do the debug build instead.
So I have the debug build that I prepared.
I have the new one.
We are still faster than the regular implementation.
So the good target, debug, call it kills.
Previews for them demo, Shakespeare.
So now if your fine is going to run it on the free binary.
So the one without my files, the one with a batch,
and the new implementation.
Ah.
Cool.
So which one it failed?
I probably made a typo in what is the command.
What?
Sort?
Oh yeah.
Merci.
Wow.
Merci.
So demo, that's fine.
Also why can we record it next time?
Yeah.
So here it is.
We can see that the new, so the first one,
that one is the one that I just patch and we compile.
It's faster than the ones that we have in three currently.
And it's twice faster than the new implementation.
So what I'm showing is not to show off.
It took me like 30 minutes.
It's not very hard to do.
And the profiler and also new tools.
The rest tool helps a lot to debug and identify
those kind of issues.
And as I was saying, it's tools that we develop for five or four years.
And it is why five or four is now as fast as Chrome.
It's thanks to all those tools.
But I'm also about five or four and go back to the presentation.
So I did the demo.
So we have been held by the Southern Tech Fund in 2023,
with the other maintainer and Google helped us as part of the Google
summer of code 2024.
And as I was saying earlier, we have proposed CI on most of the
supported platform that everything, but most of them
get up is doing a great job to provide the banner in GitHub
action.
Our code coverage is amazing.
Almost 80%.
And if you have played with code coverage, if you are both
A.T., you are usually very happy.
Here we are.
Even happier with almost 90.
We have a lot of jobs in the CI to make sure that if you
enable the adoption ends at one, it's going to work.
If you disable that one, and the other one is going to work.
And we also contribute to have three.
So we report bugs.
We send patches when they are doing something wrong.
We collaborate with them.
It's a very friendly collaboration.
So it's not we are not fighting.
And one of the cool stuff that I play with,
so Atmosier used to manage the fuzzing teams.
So I know one was two things about fuzzing,
and they told me when I discussed with them,
they told me you should fight differential fuzzing.
So what we are doing is we have a fuzzing that is going
the fuzzing, the grammar of the command.
So for example, it's XPR for expression.
So you can do some stupid math.
And it's going to generate something that it is valid,
and sometimes invalid.
And what we are doing is that we are asking the fuzzing to generate
a lot of things that are relevant and irrelevant.
And then we run the command into both implementation.
Howard and the Gnu.
And we verify if S.A.D. out.
So the standard output, S.A.D.R.
and the exit code are similar.
In that case, we can see that the Gnu error message
was not integral argument.
And our world was expected an integral occuren.
So it says the same thing.
But we consider that as a bug,
we want to be really drafting with placement
to the later in terms of error message.
And differential fuzzing for that is amazing.
If you have an implementation and you have a target
that you want to reach, differential fuzzing is really one of the
silver bullets that you can use in security,
but in compliance also.
But they know about the quantity because I'm talking about the past
and because you are all occurs and you all know about
free software and you are all most of you probably are
contributing to open source.
I'd like to tell you about what we have been working on.
So there is an old Chinese proverb that I love.
Let's say that the best time to plan to three was 20 years ago.
And the second time it's now.
And you can apply that in your life with many different ways.
And the corridors have been here for 55 years,
if you think about it.
I have friends who worked as software
and we have that.
And if you can look at the first commit of the corridors
that was done for Unix.
It was June all in four months, five months,
it would be 55 years.
And yesterday when I worked on the slide,
it was like, oh, it's actually a book.
The timestamp a book was six months before.
So it's not a coincidence.
And those things are really back from the beginning of our
industry.
And I was thinking about it.
It's like how the corridors can disappear.
Like in which world are we going to get rid of L.S.
M.C.R.C.H.Mertiation on Artist on Mac and on Linux.
Probably not.
I think we are all going to be retired when those tools are going
to disappear if they disappear one day.
And those tools still continue to evolve.
Like if you look at the new projects,
the new implementations are taking your options,
they introduce new algorithms, and we are doing the same.
And there is no reason why those tools should not evolve.
At some point we should have the discussion.
Does PR still make sense to have that in three,
probably not, but it's a different discussion.
And by the way, it's not a Chinese proverb.
I looked at that to people in my presentation,
but it looks cool.
So that's why I use it.
There is a page explaining that it is not a Chinese proverb.
It forms the U.S. in the 50s or something like that.
But I like it.
In parallel, we have been working on fine materials and different tools.
So those projects have been less of a focus of us.
But we have people who did a lot of great work.
Here, we are running the B.F.B.F.S.
Test suite against our implementation of the fine materials.
The comments that everybody knows.
And you can see that we are not fully compliant, but good in us.
And now what I like to do is to do the same with most of the essential packages on the
Debian and Ubuntu, because it's the distros that I know best.
We can ask the similar conversation with other distros.
Let's hope you love distros and Debian, but seriously.
And there is no better time than now to start that work.
So the essential packages, you use them every day.
You know about them, not all of them, obviously.
But they are still very important.
So this is a comment on Debian or Ubuntu to get the list of essential packages.
The essential packages, if you want to create a meeting.
I don't do Debian anymore.
Oh, yes.
It's more than one that's going to be there.
When you create a CH route and Debian or you boot a very tiny Debian,
it is a package that Debian needs to run.
So you all know about those ones.
They are easy, free, key, LPS.watch.
In this package, prompt PS, we have also some weird stuff.
Like PWX.
Who knows about PWDX is doing?
I implemented it in a few months ago.
It's going to tell you the current working directory of a PIG.
You want something at least today at first time.
T-load, slapped up, and so on.
Util Linux.
So you know about DMSLs, get up, our link, and so on.
There are some stuff.
Those ones don't ask me.
I don't know what they are.
I didn't pre-per for those ones.
I'm cookie and CH-woo.
I guess CH-woo, I guess CH-woo, yes.
CH-woo, I don't remember.
It could change the behavior of the kernel when you are out of memory.
Then we have some comments that we don't use in Linux in real life.
For some reason, I should discuss with people in Debion Y.
It is installed by default ACR.
It's one of the cool stuff that we don't use at the end.
We have also BSD utils.
So there are some most famous green ice to change the priority.
We have also Austin.
Login.
And you didn't see system D because I'm afraid of lernart.
I don't know if it's in the room.
I don't want to see them before.
More seriously, system D would be a beast to be right in rust.
And it would be way too complex.
We already started all those projects.
They are already live on our project.
It's called U-tills.
I think it's universal utils.
It doesn't matter what it means.
It is a name of the project.
We have already a lot of people who started contributing to those projects.
We also leveraging what we have done for the core materials.
So there are many, many functions that we have in the core materials.
That can be used for the programs as part of that world.
So when you need to monitor the system or when you need to look at the permission,
we have already also function.
We started some of some of the scum end.
I've been fully implemented.
Some of them are just one line.
It really depends.
And it's very easy to plug new tools into that ecosystem.
And we have a lot of good feedback.
So if you want to learn the rest, it's very easy.
It seems hard.
Those comments are usually self-contained.
You know the target.
We have a lot of thinking fruit.
So don't hesitate if you want to learn the rest for real.
To start those projects is where I learn.
And that's why we have so many contributors.
I think those projects, like we're writing,
we inventing the will, might some crazy.
But I think it will work because there is an appetite from the community.
We saw that the room here is the tool.
But there is a lot of people.
The talk from Miguel before was the same.
A lot of people.
So we see that people are excited by such projects.
But I was seeing earlier.
I'm beginning older.
We all do.
But the new generation is not going to want to do see.
And paving the way to do rest is also a good opportunity for them to be involved in the open source ecosystem.
We have reference implementation.
So it's very easy to test.
You can do different short-fazing as a silver bullet to help you.
And as part of that, you learn how to do fazing.
And in the rest is very easy to do.
And we are also.
I didn't know if I wanted to say that during that presentation.
But I'm going to say it is a lot of those tools that I mentioned earlier.
They are using very old pipeline system.
Some of them.
They don't have CI.
They are still using maintenance to send patches.
I apologize for the news developer here.
I still think that using maintenance to do patch review sucks.
And now with GitHub, we have an amazing opportunity to have a proper pipeline where you
can run CI.
You can run quality tools and so on.
And it is one of the advantage that we have over some of those old projects that I mentioned.
But to be clear, that works for them so I'm happy.
But I think we can do better as a community.
And I'd like to mention that it's not a much easier project.
There is no company behind it.
There is no interest from the architect in that project.
It's really I'm doing that as a passion because I can't do it.
They are in the new extension of all.
So it's really a community effort.
There is no structure behind it.
Now what I'd like to do is to finish that demo.
Sorry.
By making.
So it's a blog post that I wrote to announce that stuff.
I wrote it a few months ago.
But now I think it's time to make it public.
So make.
Project.
Click.
So here it is.
So it's probably going to be on account news in a few hours.
And last time it was number one.
It's probably going to be number one again.
I know that I'm showing off by saying that.
But it shows the interest of the community when we do it.
It's a blog post.
I don't know how quickly it is going.
Oh, no blog post.
So I guess there are some cases somewhere.
So we have to wait for the cases to be refreshed.
One more time.
It's a risk of the demo effect.
Anyway, thanks for your time.
Don't hesitate if you have any questions.
It's very easy to contribute.
There are many people who are helping.
We are using a simple PR model.
We have plenty of tests.
Don't be afraid to make mistakes.
Thank you.
Many thanks for the inspiring talk.
Perfect.
Great talk.
Thank you.
Great pleasure.
Question to the audience.
If you meet to leave early, please leave to those for doors.
Not these ones because we'd like to have the Q&A to be understandable.
Who's the first who's got any questions?
Okay.
Over there.
I'm coming.
One of the things that Gnucho co-utives has.
Do you hear me, Sylvestre?
Really?
Okay.
One of the things that you have with Gnucho co-utives is extreme
Portability.
It works on many, many platforms.
As far as I understand, you leverage the REST C portability to be able to use
REST co-utives everywhere.
Are you tracking other REST competitors?
As well as to extend your coverage?
We will when they are ready for now.
So Nikola is asking.
Can you hear me?
Yeah.
Nikola is asking the question about keeping track of the other
Compiler for us.
As far as I know, they are not there yet.
But we will.
Like it's just adding a few lines in a thermal file.
So yeah.
We will test everywhere that we can.
Any plans to do a shell like zush?
Sorry?
Any plans to do a shell?
No.
I want to replace the existing in C, not to do a shell.
There are also people doing.
There is no standard with a shell,
except using what has been done and what has been done.
The folks with a liquidity have been doing amazing work.
So there is no need in this place.
Hi.
So first of all, thanks for the talk.
And what is your stance on the other utils that have that are a part of the rewrite
it in rust, kind of trend?
What is your stance on the other utils that have that are a part of the rewrite it in rust,
kind of trend, like ripgrap, dust, bat, and all of that already exist.
And are kind of alternatives to those?
Yeah.
I think they are providing a lot of value.
Like ripgrap or FD fine and so on.
However, the issue is that they are not built in the placement.
So it's not very easy to adjust your practice.
So it's a very good project.
And the advantage that they have over us is that they don't have to maintain the argument,
legacy, and all the issues and the ordering.
Those are the self-imaging project.
I use the readgrap everyday.
Thank you.
Okay.
Other questions?
I can.
Oh, over there.
Yeah, thanks for the interesting talk.
And you also mentioned that you have this already.
The rust core utils in package for most Linux distributions.
And I have myself worked for Debian and there.
It's really, really hard to package rust packages because of these strict dependency
management.
So you have to often patch each and every dependency to have it with a less strict version
specification.
What is your experience there and how do you want to work around that in the future,
given that probably only more and more crates are added to the library?
So if I understood correctly, you are asking about packaging when it is hard to package rust
software.
Yeah, it's a dependency.
Yeah, it's a big deal.
It's because of the ecosystem in the rust.
It's quite hard to package, but I think it's going to stabilize.
And that more and more some crates have been doing a lot for years ago.
And now they are starting to be stable.
And upstream is making is more careful about the API and API changes.
So I think we are going to grind the right direction at the next time.
Yeah, I agree that it is a pain to implement in rust packages at that time.
Thank you.
Apparently no more questions.
So many thanks once more and please a applause.
Thank you.