|
1 | 1 | +++ |
2 | 2 | title = "Extending the coreutils project - Rewriting base tools in Rust " |
3 | 3 | draft = true |
4 | | -date = 2024-02-17 |
| 4 | +date = 2024-03-26 |
5 | 5 | authors = ["Sylvestre Ledru", "Terts Diepraam"] |
6 | 6 | +++ |
7 | 7 |
|
8 | | -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). |
| 8 | +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). |
9 | 9 |
|
10 | | -As we are getting closer to parity with the GNU implementation of the Coreutils, we have been thinking about what is next. |
| 10 | +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. |
11 | 11 |
|
12 | | -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. |
| 12 | +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). |
| 13 | +We also noticed a lot of contributions on these projects coming for a lot of different hackers (475 different contributors on Coreutils!). |
| 14 | +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. |
13 | 15 |
|
14 | | -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. |
| 16 | +We are |
15 | 17 |
|
| 18 | +For the next projects, we are using the same approach: dropped-in replacement of the GNU C implementation. |
16 | 19 | For now, we are going to focus on: |
17 | | -* [util-linux](https://github.com/uutils/util-linux) |
18 | | -* [bsdutils](https://github.com/uutils/bsdutils) |
19 | | -* [procps](https://github.com/uutils/procps) |
20 | | -* [diffutils](https://github.com/uutils/diffutils) (transfered by Michael Howell) |
21 | | -* [acl](https://github.com/uutils/acl) |
| 20 | +* [diffutils](https://github.com/uutils/diffutils) (transferred by Michael Howell) - [Good first issues](https://github.com/uutils/diffutils/labels/good%20first%20issue) |
| 21 | + Almost ready |
| 22 | +* [procps](https://github.com/uutils/procps) - [Good first issues](https://github.com/uutils/procps/labels/good%20first%20issue) |
| 23 | + 5 programs started |
| 24 | +* [acl](https://github.com/uutils/acl) - [Good first issues](https://github.com/uutils/acl/labels/good%20first%20issue) |
| 25 | + The 3 started |
| 26 | +* [util-linux](https://github.com/uutils/util-linux) - [Good first issues](https://github.com/uutils/util-linux/labels/good%20first%20issue) |
| 27 | + A couple programs started |
| 28 | +* [bsdutils](https://github.com/uutils/bsdutils) - [Good first issues](https://github.com/uutils/bsdutils/labels/good%20first%20issue) |
| 29 | + One program start |
| 30 | +* [login](https://github.com/uutils/login/) - [Good first issues](https://github.com/uutils/login/labels/good%20first%20issue) |
| 31 | + Just the skeleton |
| 32 | +* [hostname](https://github.com/uutils/hostname/) - [Good first issues](https://github.com/uutils/hostname/labels/good%20first%20issue) |
| 33 | + almost empty |
22 | 34 |
|
23 | | -TODO: maybe add login & hostname to the list |
24 | 35 |
|
25 | | -TODO: create and add links to the good first bugs |
| 36 | +These packages are part of the essential list on Debian & Ubuntu. |
26 | 37 |
|
27 | | -As they are part of the essential packages on Debian & Ubuntu. |
28 | 38 |
|
29 | 39 | Sylvestre Ledru, Terts Diepraam and Daniel Hofstetter |
30 | 40 |
|
31 | | -TODO: gsoc |
32 | | - |
33 | | -TODO; sponsoring |
34 | | - |
35 | 41 | FAQ |
36 | 42 | ### |
37 | 43 |
|
38 | | -License |
| 44 | +Do you hate the GNU project? |
| 45 | +---------------------------- |
| 46 | + |
| 47 | +Not at all: we often contribute to the upstream implementations when we identify issues, add missing tests, etc. |
| 48 | + |
| 49 | + |
| 50 | +Why the MIT License? |
| 51 | +-------------------- |
| 52 | + |
| 53 | +For consistency purposes and not interested by a license debate, we are going to use the MIT license just like the Coreutils. |
| 54 | + |
| 55 | + |
| 56 | +The binaries are too big? |
| 57 | +------------------------- |
39 | 58 |
|
40 | | -Binary sizes |
| 59 | +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. |
0 commit comments