"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 influ…
A Generation Lost in the Bazaar
41–50 of 353 posts
Re: A Generation Lost in the Bazaar
#42Autoconf is an easy target for these kind of rants, but you know what? It does its job, and it does it very well. The ratio of autoconf to non-autoconf programs on my system is probably 10:1, but the ratio of build problems is something like 1:20. If anyone ever managed to write a genuinely better build system, the bazaar would let it rise to the top; the gradual rise of e.g. cmake is testament to this. Trying to imp…
I hear your statement about build problems as soon as someone does not use autoconf quite a bit. However, in the past I’ve had the opposite experience: Trying to port software such as Apache, PHP or bacula to UNIX systems such as SGI IRIX, I always ended up writing a simple Makefile to compile the software instead of putting up with the multitude of autotools-fixing that would have been required. I reported one or tw…
The real kicker? It's a Python application, so there isn't much of a build process anyway. You can run it directly from source.
Re: A Generation Lost in the Bazaar
#43Autoconf is an easy target for these kind of rants, but you know what? It does its job, and it does it very well. The ratio of autoconf to non-autoconf programs on my system is probably 10:1, but the ratio of build problems is something like 1:20. If anyone ever managed to write a genuinely better build system, the bazaar would let it rise to the top; the gradual rise of e.g. cmake is testament to this. Trying to imp…
When OpenBSD replaced GNU libtool with a home grown perl version, it was so much faster I believe it literally cut days off machine time off a full ports build. For smaller packages, with tiny C files, running libtool.sh takes longer than running the compiler does. The majority of build time for some of those packages is still running configure, testing for things like , which the package provides no workaround when…
Re: A Generation Lost in the Bazaar
#44Article: This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived.
Good high-minded notions here. But configure, with it's standardized parameters for how to do stuff, is near irreplaceable at this point. Certainly a more stripped down version, one not built on M4, would be wise, but libtool/autoconf itself is used too broadly & with trepid familiarity by developers & upstream maintainers: in spite of so much of it being indeed old deprecated no longer useful cruft, the best we can hope for is duplicating a wide amount of the existing functionality in a cleaner manner.
But at what cost would reimplementation come? How many weird build targets would for months or years go unnoticedly broken?
The place where we escape these painful histories is where we leaving the old systems programming languages behind. Node's npm I'd call out as a shining beacon of sanity, enabled by the best most popular code distribution format ever conceived: source distribution, coupled with a well defined not-completely-totally-batshit algorithm for looking for said sources when a program runs & at runtimes goes off to find it's dependencies: http://nodejs.org/docs/latest/api/modules.html#modules_all_t...
Re: A Generation Lost in the Bazaar
#45Earlier quoted context omitted.
Your essay was unbalanced, yes open source sucks in the way you complained about, but Microsoft sucks even worse in some ways (if not quite as badly in others). Complaining about something in isolation is easy; everything sucks compared to perfection. But how is it compared to the real alternatives.
It amazes me that the argument against this is by attacking some "standard-bearer of his cause." Let's not ask how it is compared to existing alternatives, or to 'perfection', but rather the potential alternatives. Your argument is akin to "stop talking about 'engines'; horse-drawn carriages might suck, but so does walking."
He also mentions 'one person having responsibility'. Does he mean a benevolent dictator? Linux and Python have that. They're imperfect in their own ways too.
Re: A Generation Lost in the Bazaar
#46Matter of the fact is that the world doesn't have a critical mass of people with agreeing tastes and fundamentals to get them to come together and build something moderately complex.
What we do have however is a world full of reasonable people who just want to build something and make it work so they can solve some problem of theirs. There are also people who will happily reuse what the folks before them built - improving it in the process.
If we were to impose a high barrier to entry for people to code and design systems in absolute best possible way - we are effectively saying only a few will build software for the whole world. That'd be a net loss IMHO.
The point about bad design is worth arguing when software doesn't do what you want it to do, i.e. fails practice. But that is mitigated by the fact that individual stall in the bazaar does enforce some design, some testing, some sort of sanity to ensure it at least works most of the times.
Is it a sad situation - yes, we would be much better off with every programmer being perfect. But so long as that is impractical the bazaar alternative works in creating tons of fixable, mostly usable, continuously improved software - for which I can hardly call it a lost cause.
Re: A Generation Lost in the Bazaar
#47Yes, the bazaar is like evolution: messy, inefficient, and slow. Lots of bad ideas are tried; a lot of them stick around for as long as they provide more value than they subtract; and progress takes a long time. Just as the human body has components that are useless today (e.g., the coccyx), evolving software ecosystems always carry a lot useless baggage. That's how evolution works. But Evolution copes better than in…
... but evolution will also quite happily run you over a cliff which you have been avoided if intelligence were applied. Not to mention the fact that the bazaar is never going to put a man on the moon. And yes, I wrote that piece.
What you have to consider is that individual cells evolved, until they created a whole greater than themselves. No individual cell was in control of that first step Armstrong took onto the moon. Likewise, what we end up creating from so much "bazaar" development will almost certainly accomplish something amazing...
...without any of us being able to take credit for it.
Re: A Generation Lost in the Bazaar
#48Yes, the bazaar is like evolution: messy, inefficient, and slow. Lots of bad ideas are tried; a lot of them stick around for as long as they provide more value than they subtract; and progress takes a long time. Just as the human body has components that are useless today (e.g., the coccyx), evolving software ecosystems always carry a lot useless baggage. That's how evolution works. But Evolution copes better than in…
... but evolution will also quite happily run you over a cliff which you have been avoided if intelligence were applied. Not to mention the fact that the bazaar is never going to put a man on the moon. And yes, I wrote that piece.
I think we can see abundant proof evolution can go a long way towards that specific goal.
The reason your work machine, running BSD, works the way it does (and self-assembles that way) is because each part of its software environment is independent, designed for different goals and constraints and it just happens to work together well enough you can work with it. It would be easy to standardize Unixes, but then you wouldn't be able to compile M4 for Windows or use one of the 26 FORTRAN compilers absent from your system. Also, what happens when you realize your design led you to a dead end? Evolution usually has plans B to Z built in. It's really difficult to make something evolve into a corner.
Having plans B to Z built-in has an impact on the overall elegance and purity of the design.
Re: A Generation Lost in the Bazaar
#49I'm not a coder. And that piece illustrates why Maemo went nowhere with the general public and why Nokia's Internet Tablets failed. I tried to download software only to find out they required "dependencies." Then I had to chase those down. And once I did, I found the software to be buggy and unreliable -- and that's why people go buy iPads. They don't want to jump through so many hoops to get so little. The journey i…
That's why you need a curated package repository. I don't have to even know that "dependencies" exist to use Debian or Ubuntu; the package manager is nice enough to inform me that it determined that these-and-these other packages are required to install the package I wanted, and that it's now going to automatically install them for me, but that's just details that could be easily abstracted out.
Re: A Generation Lost in the Bazaar
#50Lambasting libtool for providing a consistent experience across star-NIX is, imo, not the wisest move for a FreeBSDer. Article: This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure ide…
And trust me, libtool is replaceable, all it takes an agreement about a compiler and loader flag for producing shared libraries and you suddenly don't need it at all.