5 ms·
"Later the configure scripts became more ambitious, and as an almost predictable application of the Peter Principle, rather than standardize Unix to eliminate t
by yungchin 14y ago
"Later the configure scripts became more ambitious, and as an almost predictable application of the Peter Principle, rather than standardize Unix to eliminate the need for them, somebody wrote a program, autoconf, to write the configure scripts."
I'm not sure I understand how the Peter Principle applies here? Autoconf seems a rational solution in the economic sense: to standardise Unix, you need to have lots of influence to effect buy-in, whereas to write autoconf, you need a big dose of hacking talent. If you have the latter and not the former...
- engtech 14y agoI had a hard time understand it as well. I interpreted it as the Peter Principle also applies to software rising to the level of it's incompetence, not just people.
- caf 14y agoRight, libtool is the same - the people that wrote it weren't in a position to demand that all the UNIX-likes out there standardise their ld flags, so they routed around the problem instead.
- hollerith 14y ago>the people that wrote it weren't in a position to demand that all the UNIX-likes out there standardise their ld flags Agree, but once Linux became the dominant Unix-like, the major Linux distros like Debian and Redhat were probably in a position to replace uses of libtool in upstreams with a distro-wide standard for ld flags.
- caf 14y agoThey could, but what would be the advantage? Such patches couldn't be accepted by upstream, and the Debian/Redhat source packages are mostly only built by Debian/Redhat maintainers, so would the juice be worth the squeeze?
- hollerith 14y agoI don't claim to know what other upstream maintainers would've done, but if I had been one in the 1990s, and Debian and Redhat had agreed on a std for ld flags, I would've announced that libtool would be removed from my project in 24 months, so other Unix-likes should get on the train.