Mail Archives: djgpp/1999/10/22/14:11:28
>> Active Zip Picker: a program made with RSXNTDJ
>> that lets the user choose the most common setup
>> (C/C++, Allegro, and RHIDE on Windows 95/98)
>> or walks the user through a set of dialog boxes
>> similar to the Zip Picker. It then checks for the
>> latest versions
The thing about an automated system like that is that it has to work
100% flawlessly in order to be any use. If there is even the slightest
potential for it to go wrong, it can actually do much more harm than
good, since the problems will be much harder to identify and work
around than if things are done manually.
In the world of free software, where each package is constantly
evolving, and being developed by different people with often only
very limited communication, it seems inevitable that problems will
always arise (a case in point being the recent changes in gcc
inline asm support, which broke many different programs). The great
strength of free software is that such conflicts are usually fixed
very quickly, but I can't help thinking that a fully automated
system would have a very hard time keeping up with such things.
Also, it is important to consider that no free software packages
can count on being constantly maintained. People lose interest,
or get engrossed in other work, students graduate, etc. So it is
important to plan things in such a way that nothing will be too
badly hurt if the maintainer goes AWOL every now and then, which
could be a problem for an installer unless it was really trivial
to configure it for all the possible changes in other software.
In my experience, most djgpp installation problems are actually
very shallow, caused by people not reading or not understanding
the docs, or random conflicts between different packages and
machine setups, rather than by any true complexity that needs
to be automated away. Maybe I'm just a cynic, but I can't help
thinking that low-tech systems have far less ways to go wrong,
plus are much easier to fix when they do...
>> No more -lstdcx bug.
>
> This is fixed in the latest RHIDE.
Which is a classic example of how development moves quickly enough
that overly automated systems can actually be harmful. Imagine if
you had written a program that knew how to work around this
difficulty: as of the new Rhide version, that special code would
no longer be relevant, and the installer would need updating to
know about this.
When things like this fail, it is usually just as easy to fix the
trouble at source as it is to implement a quick workaround, and in
this case patching Rhide can happen every bit as quickly as even
just uploading a FAQ that explains how to deal with the trouble!
Shawn Hargreaves.
- Raw text -