是的，实时上我也确实这样做的，因为它们可能糟糕到无法解决自己产生的问题。
回溯到1980年代，众多小型和微型计算机公司都跳上UNIX这辆旅行车，因为对这些厂商硬件来说会给他们一个操作系统。但是他们也尝试从竞争对手中”区分”自己，通过”增加价值”。
这些”价值”结果是不兼容。
如果存在一个编译器就开始使用，否则你绝不会知道为了这样表现的更理智些，他们应该把东西放在哪和使用什么样的参数编译。
所以，一些疯狂的点子源于 configure 脚本，这些配置通过嗅一嗅你的系统里面，并建立一个 Makefile 文件，就工作。
写配置脚本是一项辛苦的工作，一个原因就在于你需要有很多系统要测试他们运行，所以现在copy&paste就成了习惯。
后有了更疯狂的想法，源于为了配置脚本编写脚本，经过一个”史上最疯狂”人大胆的尝试，用一个不起眼且难以让人忍受，称为``m4``的宏处理器来做完成这些实施。
现在，随着发展，编写规范配置生产的宏比较乏味，所有人编写了一个工具……
...你是否检验了模式？
如果现在，这些废话的结果情况是，写一个开源代码并且能告诉文件是什么地方的工具，事实上*相信*这些事情会有结果，那么我可以忍受。
但是如果这会蒸发，那么这就不是问题原因。一方面，所有的autocrap工具增加一层版本当你获得正确结果，这些在你考虑重新编译源码前。
次，这实际上并没有工作，你仍然必须做的辛勤工作，并找出正确的方式来解释autocrap工具。你正在尝试做什么和怎么做的，只有你必须这样做以一种可以生产M4宏调用语言的方式等。
在此期间，UNIX的多样性在50多个显著不同的方面，只有少数缩水：Linux, *BSD, Solaris和AIX 还有autocrap工具都已变成了问题的一部分，而不是解决方案的一部分。
Varnish中生成autocrap的问题是：
……
有一天有时间时，我会撕碎所有autocrap所有的东西，然后用5行shell脚本取代，可以叫 uname -s .
Poul-Henning, 2010-04-20