improve the blog post

This commit is contained in:
Sylvestre Ledru
2024-03-26 23:45:20 +01:00
parent 7fd8e0accb
commit 98aec3e625
+38 -19
View File
@@ -1,40 +1,59 @@
+++
title = "Extending the coreutils project - Rewriting base tools in Rust "
draft = true
date = 2024-02-17
date = 2024-03-26
authors = ["Sylvestre Ledru", "Terts Diepraam"]
+++
Over the last 4 years, we have been working at reimplementing some of the key linux tools in Rust. We started with the [Coreutils](https://github.com/uutils/coreutils) and [Findutils](https://github.com/uutils/findutils).
Over the last 4 years, we have been working at reimplementing some of the key linux tools in Rust. We started with the [Coreutils](https://github.com/uutils/coreutils) and [findutils](https://github.com/uutils/findutils).
As we are getting closer to parity with the GNU implementation of the Coreutils, we have been thinking about what is next.
As we approach feature parity with the GNU Coreutils implementation, and as its adoption in production environments continues to expand, we have been thinking about what is next.
Given the overwhelming positive feedback around this initiative, we are going to extend our efforts to rewrite other part of the modern Linux/Unix/Mac stack in Rust. We also noticed a lot of contributions on these projects coming for a lot of different hackers. Rewriting in Rust will help with the longer term maintenance of the ecosystem, ensuring it stays robust and welcoming for new generations of contributors.
Given the overwhelming positive feedback around this initiative, we are going to extend our efforts to rewrite other part of the modern Linux/Unix/Mac stack in Rust (still with Windows support in mind when relevant).
We also noticed a lot of contributions on these projects coming for a lot of different hackers (475 different contributors on Coreutils!).
With the growing enthusiasm for Rust and the eagerness to learn it, now is the best time to push this project. We think that rewriting in Rust will help with the longer term maintenance of the ecosystem, ensuring it stays robust, safe and welcoming for new generations of contributors.
For the next projects, we are using the same approach: dropped-in replacement of the GNU C implementation. For consistency purposes and not interested by a license debate, we are going to use the MIT license.
We are
For the next projects, we are using the same approach: dropped-in replacement of the GNU C implementation.
For now, we are going to focus on:
* [util-linux](https://github.com/uutils/util-linux)
* [bsdutils](https://github.com/uutils/bsdutils)
* [procps](https://github.com/uutils/procps)
* [diffutils](https://github.com/uutils/diffutils) (transfered by Michael Howell)
* [acl](https://github.com/uutils/acl)
* [diffutils](https://github.com/uutils/diffutils) (transferred by Michael Howell) - [Good first issues](https://github.com/uutils/diffutils/labels/good%20first%20issue)
Almost ready
* [procps](https://github.com/uutils/procps) - [Good first issues](https://github.com/uutils/procps/labels/good%20first%20issue)
5 programs started
* [acl](https://github.com/uutils/acl) - [Good first issues](https://github.com/uutils/acl/labels/good%20first%20issue)
The 3 started
* [util-linux](https://github.com/uutils/util-linux) - [Good first issues](https://github.com/uutils/util-linux/labels/good%20first%20issue)
A couple programs started
* [bsdutils](https://github.com/uutils/bsdutils) - [Good first issues](https://github.com/uutils/bsdutils/labels/good%20first%20issue)
One program start
* [login](https://github.com/uutils/login/) - [Good first issues](https://github.com/uutils/login/labels/good%20first%20issue)
Just the skeleton
* [hostname](https://github.com/uutils/hostname/) - [Good first issues](https://github.com/uutils/hostname/labels/good%20first%20issue)
almost empty
TODO: maybe add login & hostname to the list
TODO: create and add links to the good first bugs
These packages are part of the essential list on Debian & Ubuntu.
As they are part of the essential packages on Debian & Ubuntu.
Sylvestre Ledru, Terts Diepraam and Daniel Hofstetter
TODO: gsoc
TODO; sponsoring
FAQ
###
License
Do you hate the GNU project?
----------------------------
Binary sizes
Not at all: we often contribute to the upstream implementations when we identify issues, add missing tests, etc.
Why the MIT License?
--------------------
For consistency purposes and not interested by a license debate, we are going to use the MIT license just like the Coreutils.
The binaries are too big?
-------------------------
Does it really matter? Yes, Rust binaries are usually bigger then GNU but we don't think it is a blocker, even for embedded devices.