Skip to main content


People are afraid of running unaudited `curl | sh`, but nobody bats an eye on 24707 lines of obfuscated garbage in `./configure`.

#xz

#xz
This entry was edited (1 month ago)
in reply to daniel:// stenberg://

@bagder Sure, but risks of binaries are rather obvious.
./configure seems to have flown under the radar due to counting as “source” despite not being much clearer than a decompiled binary.

To me this is such an unnecessary risk. It’s a slow awkward build system, and the reason it’s like that is due to its only unique selling point: support for platforms so obscure that museums don’t even keep them on display.

in reply to Kornel

but that's just your opinion and frankly, there are no alternatives without at least a corresponding set of (other) flaws
in reply to daniel:// stenberg://

@bagder I know. It’s incredible that this should be a solvable problem, and yet C only has variously problematic build systems, and chronically terrible dependency management.
To me the most depressing thing is that has always been like that, and there is no hope of it ever getting better, because in C time has stopped in 1989.
in reply to Kornel

and at the same time, none of the new fancy languages can do system libraries proper with dynamic linking etc. Which C solved already before 1989.
in reply to daniel:// stenberg://

@bagder Dynamic linking is entirely orthogonal to this, and it's not C vs other langs. It's C being unable to fix anything.
Most autotools tests should have been compiler features, or standardized to remove pointless fragmentation. But in C it's impossible to fix even smallest problems on a timeline shorter than a decade or two, status quo is accepted as that just how things have to be. Often there is no will to even try, because it won't be compatible with C89.
in reply to Kornel

I disagree with just about all of that. As you probably could've guessed.