commit: 7a7e5a55e44059a87f9fac2ee3a4b1939f06aba4
parent 118c21b80cea33858ffe769b9e816fb5c058f328
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date: Sun, 16 Mar 2025 19:08:25 +0100
README: reword coreutils difference and non-goals a bit
Diffstat:
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
@@ -52,7 +52,7 @@ When works are imported from other codebases they should be either under a permi
### Difference with coreutils
-Straightforward code, similarly to glibc, coreutils codebase often has it's actual code hidden under layers of macros and wrapper functions.
+Much more straightforward code. Similarly to glibc, coreutils codebase often has it's actual code hidden under layers of macros and wrapper functions.
### Difference with BusyBox/ToyBox
Instead of minimalism as a constraint, here it is seen as a virtue of good design and as such as a process/long-term-goal.
@@ -68,6 +68,6 @@ utils-std default license is the MPL-2.0 to be able to take code and design back
- Efficiency, but not without sacrificing the other goals
## Non-Goals
-- Reimplementing complex utilities that already have great code or ought to be maintained separately
+- Reimplementing complex utilities that are typically maintained separately (such as sh, awk, yacc, tar/pax, …)
- Implementing utilities which aren't in your usual base system. This is covered by [utils-extra](https://hacktivis.me/git/utils-extra), and I'd also recommend checking out [moreutils](https://joeyh.name/code/moreutils/)
- Reimplementing OS-specific utilities like [util-linux](https://www.kernel.org/pub/linux/utils/util-linux/)
