Zack Weinberg writes about GNU Autotools, compilers, Unix, web privacy attacks, UTF-8 and policy topics like tax design.
HN commenters praise his Autotools SWOT analysis as readable and a sharp critique of autoconf, and link his thread-safe environment variable draft.
There's been a relatively comprehensive take-down on autoconf (1), that boils down to:
It's an old piece of software, with basically no maintainers, which is fantastically difficult to make any changes to.
Not... stable because it "just works"; unchanging because it's so enormously complex to make and coordinate even trivial changes, that it is effectively the peak of the software lifecycle, where something has accumulated so much technical debt you can no longer make changes to it.
...so; in that context, being a fan of some features that autoconf supports is interesting, but, makes absolutely no difference to the reality; that it needs to die in a fire and be replaced.
Software, that you cannot change, is dead. Especially a build tool, that has failed to be maintained to changing needs of developers.
If autoconf wants to live, people need a comprehensive plan to maintain it, not to sing praises of its current, clearly bad, state.
> it has been popular to suggest that Autoconf should go away.
Yes.
...because no one has a plan to maintain it or fix it.
> Some of the people suggesting this have also been proposing that the replacement for Autoconf and the 'configure' scripts it generates be something simpler.
Specifically who?
Build systems are hard. No one serious, who understands what they're talking about and the context around it that I've seen is suggesting this.
...most people, seem to consistently be suggesting that the current state of autoconf is…
Yeah, I'm being salty, but at the same gcc is notoriously unapproachable while also struggling to pull in new blood. Considering the long, but sporadic update history [1] of this documentation, I am not optimistic about this effort turning it around. Seems more likely to become yet another one of the out of date or incomplete tutorials lying around [2]. GCC's own contribution docs [3] cop to the fact that most new contributors are doing paid work on behalf of chip and system designers, so for GCC's sake I hope it remains the must have compiler for new chips because that seems to be its main source of fresh blood at this point. This blog post [4] from a GCC and autotools developer popped up on here a month ago, and while it doesn't address GCC, if you squint I think you can apply most of the criticisms to GCC as well.
[1] https://github.com/davidmalcolm/gcc-newbies-guide/commits/master
[2] https://gcc.gnu.org/wiki/GettingStarted
[3] https://gcc.gnu.org/contributewhy.html
[4] https://www.owlfolio.org/development/autoconf-swot/
The OP, Zack Weinberg helpfully published his analysis on his own web page¹ and the formatting (different typeface for headings, flowing paragraph text, hypertext links, bullet points) made the analysis much more readable.
I think email is fine as the communication medium for software projects – particularly for projects that have been around for as long as Autotools†. For me, the biggest downside is that not all mailing lists use GNU mailman or other listserv software that provide archiving of list posts. Having a searchable archive of discussions is invaluable.
† though I was surprised to see a number of contributors top-posting; that practice was universally discouraged on Internet mailing lists until the number of new members using MS Outlook overwhelmed members who followed the established “netiquette”
1. https://www.owlfolio.org/development/autoconf-swot/
This is getting interesting. For me on Windows 7 Firefox (both 7.0.1 and the current Beta version), Chrome, Safari and Opera all have this issue while IE9 does not. Which version of Firefox are you running?
Edit: Additionally, if I use the so-called "F12 Developer Tools" in IE9 to switch the browser mode to IE8 the font will have the same problem.
Edit 2: I found this article http://www.owlfolio.org/htmletc/legibility-of-embedded-web-fonts/ - I also found a few references to being able to activate hinting for the fonts used in the embedding process. Not sure what the options are from TypeKit (the service used on this site) and I can't check on my own TypeKit account as their website is currently down for maintenance.
> Don't they understand that it is not technically possible? People will just start using VPN.
Maybe it is not possible to completly stop it, but they could just implement severe punishments for trying to connect to services like TOR, I2P and VPNs. The traffic is definitely detectable, (here is a project that tries to make it harder to detect TOR traffic http://www.owlfolio.org/media/2010/05/stegotorus-talk/). Even if they can't catch them all they can catch and punish enough people to make it to dangerous to use a VPN/TOR/I2P to not make it worth the risk to access the uncensored internet.
Meh, there's a reasonably large amount of research on disguising Tor traffic nowadays. Two recent interesting papers were StegoTorus [1], which conceals Tor traffic via steganography in a way robust to the above statistical analysis, and -- more exotically -- SkypeMorph [2], which obfuscates Tor traffic to mimic Skype traffic.
[1] http://www.owlfolio.org/media/2010/05/stegotorus.pdf
[2] http://www.cypherpunks.ca/~iang/pubs/skypemorph-ccs.pdf