diff --git a/site/blog/2025-07-20-no-gnulib.md b/site/blog/2025-07-20-no-gnulib.md index 91b24a0..f66599f 100644 --- a/site/blog/2025-07-20-no-gnulib.md +++ b/site/blog/2025-07-20-no-gnulib.md @@ -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.