Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: Ambitious suggestion for a DJGPP add-on Date: Fri, 22 Oct 1999 13:57:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com >> 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.