Alright, so we now have Ruben who's going to tell us his war stories about rewriting
and things in rust and take it away.
Thank you.
Could we have some quiet?
Okay, thank you.
Alright, let's get started.
So I'm going to talk about rewriting system software in rust.
And to this point, some of you, I'm just going to talk about none.
And then finally around 2017, I had my first commercial project, which was a map server binding
to rust and map server is this mapping software where you can sort of make your own Google maps.
So that's pretty cool.
And then from that point on, it sort of became bigger and bigger and bigger.
So then finally, in January of 2022, we got our first open source project that we could actually do for rust.
Our company already worked with all of this open source software, but that was the first time that we actually made something new.
And it was sort of because COVID and work was a little bit slow.
Well, let's do some open source development.
So we got this grant from the AnilNet Foundation, where we were out to make a PTP prototype, precision time protocol, which is a time synchronization protocol.
And then around April of that year, we got into contact with Prostimo from the Internet Security Research Group, the Let's Encrypt People, to implement NTP in rust,
is the other time synchronization protocol, isn't that a coincidence.
And then finally, in December of that same year, I started to reach out again.
And we were allowed to make a sudo implementation in rust together with the folks from Fair Systems in Berlin.
And that was a real fun project to do as well.
So we had some work for a couple of months.
And then finally, in August of 2023, we got a massive grant from the sovereign tech friends, which is a German government-ish-based organization.
These days they're called the sovereign tech agency.
For our NTP and PTP work together in a project that we called pendulum.
And then finally, in April of 2024, we were like, well, this is getting quite a lot.
Let's make it into a non-profit foundation.
And that is what my shirt is all about.
It's the Fairfax tech foundation.
So all of our open source work is now in a non-profits organization.
So what then does Fairfax accurately do?
So we have sort of four main things that we do.
First, we have time synchronizations or the pendulum project, the PTP and NTP work.
Then we have the privilege boundary, which is sue.
Then we have data compression, which is ZLIP and BZIP.
And we have a smart grid protocol, which is open leader, which is automatic demand response protocol for the power grid.
And then we have sort of two sort of secondary things, which is TTRS, which is our education project, where you have an open source university education course.
Which you can try out.
And then finally, we have this sort of site project born out of ZLIP, mostly, where we want to make Rust faster than C.
Because sometimes there are these edge cases, especially with ZLIP, where Rust's code gen isn't quite the same as we can do with C.
So there are still something to be gained there.
And our tech line is sort of then open infrastructure software for the public interest.
So what is system software? And I looked up on Wikipedia and Wikipedia system software is software designed to provide a platform for other software, which is a little bit vague.
And I don't really have a good definition of what system software is, so it's going to stay a little bit vague.
But I say generally, system software is a little bit low level software, it's not like a web page or something.
And generally, it's relatively low overhead and generally relatively high performance.
And then most of the time, you're sort of implementing protocols, algorithms and formats, like NTP, PTP, ZLIP is a format and then sudo, it doesn't really fit into any of these.
So apparently it's not just this, it's more than that.
So it's got something to do with a little bit more foundational software for your system.
So why did we pick all of these projects that I just showed you on the previous slides?
And basically the main thing here is it's got to be interesting.
It's got to be something that's going to be fun to do for a long time because this is something that we want to keep on doing for a longer time.
So not just something where it's like just earn some money and then just put it out there and then not maintain it anymore.
This is got to be something that's going to stay up for a longer time and it's got to be relevant for a longer time.
So what if you were to do this for your own?
I'd say like we'll just start with the projects with the most buffer overflow issues, right?
And I mean sure you can do that but it's also quite limiting because it's not just buffer overflows where the rest is better than the rest.
It's a little bit more than that.
And also if you try and do this too much then you might turn into the rest evangelism strike force.
And that's something where you can get some irritation by some people if you do that too much.
So like don't turn into this crow that's that's someone saying something and then have you tried rosts.
It's memory safety you know.
So do a little bit better than that.
So just rewriting and rost is not enough is my sort of statement here because she got to be careful about those negatives.
Because every time you just say I'm just going to rewrite it in rust and then everyone's going to have to deal with that.
You're splitting communities because maybe not everyone likes that you're writing it in rust.
And maybe not everyone wants you to write it in rust.
And then also users won't see those changes.
If you're just rewriting in rust and then they'll think oh this part is just two kinds of things.
So for example entropy if we are at the IATF and to be working group the average age is about 60 or something.
And then we're trying to bring that age a little bit down because this is important so far that everyone is relying on everyone wants their computers to have the current time.
But then if all the people that are working on this are slowly aging to the end of their working life then yeah you're sort of starting to get a bit of a trouble there.
And there's also other pieces such as the sudo software is developed by one single person and one single person only and everyone's relying on this tool.
But there's only basically one person who knows how this software works.
So again something where I would say that's not a good situation to be in.
Other things to look at is does that project have a history of security issues.
I'm not just memory safety issues but security issues in general because security issues don't just have to be memory issues.
There can be lots of security issues.
So if a project has security issues quite often then probably there's something fundamental going on and maybe the rest types system are the rest.
Like way of thinking about things can actually help in that specific domain.
The other thing to also note there is is if you have unstructured code bases where things are just randomly going through and maybe again the rest type system is something that can help or the rest way of doing things.
And the final thing I'd note here is that all of these projects are not specifically related to rest because all of these things are about system utilities.
That are meant for like the whole computer as the whole computer and operating system as a whole and not specifically something that's related to rest.
So let's say we found that magical project that could use some rest.
The first thing I'd say is do you already know like the entire problem space are you aware of all the intricacies in that specific problem space.
Because if you're not then just start a hobby like start to enjoy this stuff because otherwise you're going to burn out at some points and then like you created some code and then this is just going to live on get up and then no one's going to look at it and that's not great.
I mean it helps you learn stuff but if your goal is that you want to evolve the ecosystem and then just making some code on get up is not enough I will say at least.
And the other thing I'd say is even if you think well breasts fine just let it exist and I don't really care about it.
I'd still say encourage people to try do something with rest because encouraging those people might also encourage those people to enjoy to join your ecosystem of your specific protocol or algorithm or whatever.
So it's sort of widening your user base.
And make sure when when you're looking at this to look at competing implementations as well look at every implementation that's there be where do if you're working on something with like GPL and you're thinking oh I'm going to write this in MIT and then you might run into some licensing issues as well so like there's caveats.
So this is sort of my business side here is saying well we have to think about something other than just memory safety type safety.
We have to think about this unique selling point for our new implementation for this protocol idea or whatever.
So we have to find some unique selling points and this is very business speak but sure.
Because we we respore on us we we really enjoy our type safety and our memory safety but that's not something users looked at all the features that were in sudo which is quite a lot.
It might be surprising because I did notice I just thought it's a way to get to root but it does like a thousand things it has a thousand features and then maybe some of those features were not necessary for almost everyone.
And we kind of chose to limit the number of features that that were in our implementation but still made it usable for almost everyone that uses sudo in a daily basis.
And then for anspdrs for example we focus on network time security that which is a secured variant of network the network time protocol which is completely unscured and uninterrupted and whatever.
So there's again a focus on something specific other than the rest programming language.
Or maybe you could focus on performance because that's something that rs can do.
But maybe then add a little bit of fun safe even though that was the thing that you shouldn't do.
Maybe that little bit of unsafe can actually make your program faster and if you can explain your little bit of unsafe away then sure maybe that's fine.
So for example in Z Flip we use a lot of simply instructions which are unsafe.
But we can explain why we need those specific instructions to make it fast.
So we can sort of explain why this is okay to do.
And of course if you're thinking about performance then make sure that you actually verify those things and you create some benchmarks and of course there is always problems with benchmarks.
But like have some proof that you're actually fast.
Another thing we could do is focus on stability and stability.
I can sort of see that in two ways.
Maybe think about memory leaks because for us doesn't protect against memory leaks.
If you can just leak a box and then it's gone and doesn't get cleaned up.
And there are lots of other ways in which you could leak memory because that's not a memory safety issue.
But it is a stability issue because if you keep on leaking memory for our process that's supposed to long for run for a long time then well you run into problems and users get irritated that your software isn't great.
So maybe that's something you can focus on and show that actually this thing can run stable for a long time.
Which could look at this in another way in stable APIs.
You can have APIs that maybe don't change for a long time and you know that this API is going to be there always and you can trust on it.
Which is for example the way we did it in Z Flip where our C interface or the C interface that already existed for is that the poor a very long time is the primary interface but which you use at the press.
So that sort of guarantees that we have a stable interface and that won't change for a long time.
And for NSPDRS we very quickly started working toward a one point over release where we had stability guarantees about which parameters and which functions were stable in the whole project.
So focus on your strength and use that strength to help others even if that other project is not written in Rust because that sort of makes the whole ecosystem better and not just your project.
That's what I think this is all about like Rust is all about making things better and the only way to make things better sometimes is to even look at those other implementation even if they're in C and make sure that they also get better.
So for example with NSPD we want to make sure that C implementation support the same protocols as we do so everyone can use that network time secured.
And basically be to change you want to you want to see make sure that that you show the way to make things better and then other people can adopt your way of changing things.
So help those other implementation and document what works in your implementation what doesn't work in your implementation.
Another way to look at focuses for example are NSPD and PCP implementations both have different algorithm for basically determining the time offset.
And that offset is that that algorithm is something new compared to the rest of the ecosystem because it's sort of self-learning a little bit it's not AI.
I'd say it's not AI.
But it's self-learning it's tuning automatically based on the environment and that's something that our NTP and PTP implementations don't have.
So that's something where we can say we understand this problem domain and we thought aware of like algorithm choices and such.
We were just implementing the protocol itself and just doing whatever was needed to get to get this started.
And then after a while we learned sort of ways in which we could improve the situation and that's where our own algorithm came into play.
And that sort of changed a little bit our unique selling point.
So take some time.
So no rush.
Don't worry about all this publishing on Chris so that I know and making sure that's releases.
Just focus on like sort of going through all this code and going through all these algorithms and let this flow a little bit and take some time and no rush.
I mean get a person going anywhere crazy so they're always not going anywhere.
Don't worry.
So while you're working on your projects I do have a couple of ways in which I want to take some points of attention here specifically documentation dependencies and distribution.
So first documentation.
Okay there's a little bit of first code here.
So obviously you have this for bit missing docs and for bits and documents that say unsafe block so all your code is perfectly documented so you have your documentation in place right.
You don't need anymore documentation.
And you have I don't know you maybe have duct tests and written in every case so you can even see examples of how to use this code but.
I would say that's fine that's that's great that's reference guide that's that's the rest of you for you.
But that's not what users use because users use like a book like the programming language which is like the thing that you used to get started with rest before you look at the reference documentation before you look at which methods are available at a vector.
You need to understand what this language is all about and that's the same for your project as well because users.
Sort of understand the global principle of your your piece of software but they don't understand the specific implementation details and the documentation that rest of the rights is all about implementation details I'd say.
So you need other stuff you need examples you need tutorials you need a high level guide you need sort of reference guides for.
The actual like usage of your program and that's other documentation than just rest dogs.
So that's something where I think you need to take care of that stuff to make your project like the best project it can be and also to show other people like what your project is actually doing.
And then dependencies that's that's not a thing that we sort of had to find out because dependencies solve problems that.
So so we don't have to do it ourselves so we can just take in a dependency and that will solve a certain problem and then we just use some code from them.
And the rest ecosystem does offer a lot of libraries that we can use but they're all of varying quality and varying ways in which you like sort of know what the dependency is all about.
But if you're a new project I'd say just use everything you can because you need to focus on getting your problem solved first before you're focusing on these kind of things.
But then after a while you're a nice stack of boxes turns into this like horrible or library or whatever.
And that also means that you have to trust all of those people and if you look at just a small project you probably have hundreds of people were sort of secrets.
Collaborators with your project and yeah that there's a certain risk there.
Something that you need to be aware of like can I trust these people and is this something that I want to have in my own program.
So you have to take all of that into consideration.
For example in in suitu we had this this password prompt library but that password prompt library was never used in a context where suitu is used where suitu runs as a set UID binary.
Which is a binary that you can call and then it runs as roots or as the user that the the binary zone by even though you yourself are not root.
So that's sort of a scary context to run in so you need to be aware that all those libraries that you're using are actually aware that they're running in that context and generally library authors are not aware of that because like who who's going to think that they're going to run as a set UID library no one's going to think that.
That's why for at least two or us we basically removed almost every dependency that we had and we now only have four which are like log and something like lipstick or something so like very basic dependencies only because.
All of these dependency authors and we can't like I don't blame them because I can't expect everyone to run in a set UID context.
So that's something where our use case differ from all of those library use cases and we had to reevaluate all the dependencies that we had included initially.
So dependencies trusting is nice but verifying is better.
You can use tooling like cargo vet to make sure that all of those dependencies are actually audited that someone has actually looked at the changes since the last time and you can do that yourself you basically have to do that yourself.
We can also sort of share the load with other people so especially the people from Mozilla do this a lot day they basically every dependency that they have they they audited and then they sort of added to their list of what it dependencies and then you can sort of say well I trust Mozilla to do the right thing and I'll pull in everything that they verified and then I can add my own verification on top of that and then I can sort of build this web of trust of dependencies.
And there's another thing about dependencies and that's about the distribution story and this is where I'm sort of going off a little bit.
And if you're working with Linux and one of the targets for your Linux based program is going to be deviant.
And deviant chooses to package each individual dependency just one version as a source package on deviant which means that all of the libraries all of the programs that that are posted on deviant all of to share the same version.
Of that specific library which means that you're sharing the same version with all of the other tools that deviant wants to grab and pull in to there.
So that's something that you need to be aware of and it's not specifically to call a deviant that there are way of packaging things is weird or something because that's just the way that deviant works that's just the way that you have to do with stuff.
But I'd say that's fine because like I see the distributions that eventually take apart software as sort of our contributors as well because they eventually are ending up putting their software into their distribution.
It's not my distribution, it's their distribution and they have their ways of working there and we sort of have to accept that that's just the way that they work.
If I want to get my user-based as large as possible, that's just what I have to deal with as a software package maintainer.
And like I might think that maybe the rest way of doing things is better and maybe I do think that, but I still have to deal with this.
So again that's something where you just need to be aware and just need to know that these kinds of things happen all of these distributions have their own sort of ways in which they want to do stuff and I need to accept that.
This is the way that they actually do stuff.
We made by just supporting the widest ecosystems so I need to support all of these different distribution.
I need to support all of them because then I have the widest install base and I can get the widest usage of my package.
But still you probably want to push to create so they are because lots of the things still still want to use great so they are as their source.
But then whoops, my crate is not available because someone decided that NTPDRS is perfectly a great name and then we'll just register NTPDRS and then you look at the source of the package and there's just like 10 lines of code in there because someone decided, well it was just a great idea and then they dropped it.
And that's sort of maybe a little bit irritating because then you're like, but I actually made it instead of you just pushing 10 lines of code but I'm just giving a lot of our name I'd say.
And that can be harder than you might think because NTPDRS is a pretty generic name, it's just NTPDRS.
But we tried to change the name, we tried to think of new names but that's sort of fails because we were getting into this phase where we're thinking names up by committee sort of everyone voted for their favorite name and then eventually like no one could agree on what what was then the perfect name for this thing.
So we just contacted the person who owned the package name and they said sure I'll transfer it to you and the program was gonna wait.
So but it helps if you have something to show because we only did this once we had like a working thing we actually could show that we had NTP so far.
So in the end after all this you need to build a trust.
You need to build a trust with users, with contributors, with dependency maintainers, but also with downstream maintainers.
All of these people, all of these different people with all of these different goals and ideas, you all need to show to all of those people that you're reliable partner that you have the knowledge to like sort of get this working.
And then like this this is something that takes time because there's no way around this you need to show that that you can do this for a longer time.
And the one thing I would specifically add here is that you need to have a way to handle security issues.
You need even if you just set up a simple email address that's fine or if you set up like get up advisories or something at that time.
But you need to have a way to let users know there is security issue and you need to have a way to contact you about security issues without creating a public issue.
So you can actually fix the thing before everyone knows about it.
So that's the one thing I would really advise you to do something.
So we picked that project that needed rust, rewrite it in rust treatment.
We found something to focus on that uniquely identified our project.
We iterated and created the best software package ever.
We made the best documentation ever surely.
We limited trusted and verified all of our dependencies.
We distributed the software to the wideest audience possible.
We've communicated to everyone so everyone's now really trust us.
So what are you waiting for?
Any questions?
I just remind people to remind people to not get up and make loads of noise leaving until the questions are over thanks.
Hello, thank you.
How can the rust community avoid to run into the maintenance problems?
Let's say after the height.
I mean the question of course is if rust is really high for not.
I'd say it's not.
It's actually something that really shows that it works.
But other than that this is I'd say it's mostly a funding problem.
Like we're doing this as a company and as a foundation.
Like we're not running this as individual users.
But we're running this as like a company with more people than just one.
And that's sort of our way in trying this with eventually.
This is just a funding problem and I don't have the answer to a funding problem.
There is a funding difference tomorrow.
So maybe they have more answers to that.
Everybody knows the story.
Everyone should trust that it will do the right thing.
But then it turned out that it didn't do the right thing.
Because no one looked at it.
Okay, if there's no more questions, thank you Rubin.
Thank you.