RGBCube/Site
1
Fork 0
mirror of https://github.com/RGBCube/Site synced 2025-07-30 12:37:50 +00:00
Code Issues Activity Actions

blog.no-gnulib: update

Browse source
This commit is contained in:
RGBCube 2025-07-20 00:19:04 +03:00
parent 7a7eb76262
commit 530c4f6b49
Signed by: RGBCube
SSH key fingerprint: SHA256:CzqbPcfwt+GxFYNnFVCqoN5Itn4YFrshg1TrnACpA5M
1 changed files with 25 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

42
site/blog/2025-07-20-no-gnulib.md
View file

@ -6,6 +6,12 @@ description: ...and Debian.
If you are a GNU maintainer and are not willing to be critizied by people sick
of your bullshit software, do not read this post.
Also, obligatory notice on every post that touches GNU: No, nothing in this post
is political. I am perfectly fine with using GNU licensed software, and find it
more favourable than MIT licensed software as it protects user freedoms. (My
personal choice however is MPL, as it doesn't redeem your software dead on
arrival at places that actually make money and feed hungry mouths)
---
# Say NO to Gnulib
@ -15,35 +21,37 @@ coreutils (or any other GNU tool that depends on Gnulib) for anything other than
the most core-level bootstrapping needs is that it depends on Gnulib.
Gnulib is a huge blob of C and 80 thousand lines of m4 that has crusted over 30+
years and is almost impossible to build correctly, has to be manually patched in
every single program that embeds it, [^Gnulib is not a library, but a collection
of source files that you are supposed to embed into your program, so you can
expect to be pulling your hair out as it is well-rooted into most programs that
embed it. Have fun packaging it all!] rewards bad OSes and makes good OSes
shrivel in pain & makes packagers go bald & makes issues hard to diagnose and
debug.
years and is almost impossible to build correctly and hermetically, has to be
manually patched in every single program that embeds it (if trying to be
hermetic, and correct), [^Gnulib is not a library, but a collection of source
files that you are supposed to embed into your program, so you can expect to be
pulling your hair out as it is well-rooted into most programs that embed it.
Have fun packaging it all!] rewards bad OSes and makes good OSes shrivel in pain
& makes packagers go bald & makes issues hard to diagnose and debug.
It's so ass. It's so incredibly easy to build it wrong and create a shitty
distro (and it is built _wrong_ by default). At least in Rust (or in other
ecosystems, such as Go) and the general ecosystem of Rust, `Cargo.toml` is
It's so incredibly easy to build it wrong and create a shitty unreplicatable
distro (and it is built non-hermetically by default). At least in Rust (or in
other ecosystems, such as Go) and the general ecosystem of Rust, `Cargo.toml` is
pretty well-defined and `build.rs` scripts don't do anything that insane. (Hell,
even the [C compilation tools used inside crates](https://lib.rs/cc) are shared
deps and is well-defined).
deps and are well-defined).
I don't trust the average distro to build any toolchain made by GNU properly,
and I do not trust them to produce a proper set of system tools eiyher because
of Gnulib.
and I do not trust them to produce a proper set of system tools either because
of Gnulib and other bad build tools.
I do however trust the average distro (not Debian, they are lower than average
and suck at packaging [(Yes, really.)](#debian-sucks-at-packaging) to build
Uutils tools & any other Rust tool correctly, because it is pretty relatively
straightforward compared to hundreds of thousands of lines of ancient m4. Much
easier to audit too & it doesn't misbehave or segfault.
straightforward compared to hundreds of thousands of lines of hard to audit &
ancient m4. It also won't misbehave or segfault when you interact with a
misbehaving NTFS partition.
I hope Uutils coreutils & Uutils findutils and so on achieves near perfect
I hope Uutils coreutils & Uutils findutils and so on achieve near perfect
compliance so I do not need to serve GNU tools to my users.
> Also, keep in mind that it doesn't have to be Rust. I would also welcome the
> Also, keep in mind that it doesn't have to be Rust or uutils or anything that
> is shilled by the "Rust Strike Force" in particular. I would also welcome the
> GNU people fixing up their shitty build tooling & making their software behave
> correctly. But that isn't happening any time soon, so we are starting from
> scratch & fixing (quite) a few itches on the way.