Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Sasl-enc: twieri3wGIPhZaAtUhnSrA 1068272823 Message-ID: <3FAC8D41.2000100@cwilson.fastmail.fm> Date: Sat, 08 Nov 2003 01:29:21 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Collins Cc: cygwin AT cygwin DOT com Subject: Re: cygwin patches integrating back into standard gnu References: <3FAABE0A DOT 6090406 AT ekers DOT idps DOT co DOT uk> <1068154769 DOT 3faabf91a071f AT www DOT nexusmail DOT uwaterloo DOT ca> <20031106222357 DOT GA25195 AT redhat DOT com> <20031107023331 DOT GA16244 AT mdssdev05 DOT comp DOT pge DOT com> <3FAB099D DOT 9090705 AT cwilson DOT fastmail DOT fm> <20031107191452 DOT GB16244 AT mdssdev05 DOT comp DOT pge DOT com> <3FAC62E6 DOT 8050404 AT fastmail DOT fm> <1068267566 DOT 1188 DOT 43 DOT camel AT localhost> In-Reply-To: <1068267566.1188.43.camel@localhost> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Collins wrote: >>But they didn't really pursue this too strongly -- instead, they focused >>on attempting to make the transition smooth ('autoupdate', etc). They >>ignored the network-stasis effects (essentially, a classic 'deadlock' >>problem: you first, no you first...) > > > Yes, and IMO a nutso one. Coexistence is more important than smooth > transition in the absence of a dictator forcing concurrent upgrades. Yeah. You know, every time this subject comes up I'm reminded of an essay I saw online a few years back. It had to do with that bug-a-boo we all like to criticize MS for: their insistence that old programs work on new OS's. We whine that this restricts modern platforms by subjecting them to the bad decisions of the past. The essay on the other hand said that coexistence -- I can keep my old programs even after I upgrade my OS -- is what led to MS's unprecedented dominance. It counterintuitively allowed people to upgrade *their APPS* faster! (What? Because I can run OldApp on NewOS, I'll buy NewApp sooner? Yep.) Without coexistance, you're faced with an all-or-nothing proposition. Like Apple's uphill "switch" campaign. Get the better OS -- and simultaneously ditch all of your old apps. Replace them all at the same time -- with this month's paycheck. Or go without for months. Or keep two computers up and running ("Honey, I've got to do Quicken..." "Oh, that only works on the kid's computer now...") So, you stick with OldOS and OldApp until it just gets too damn painful. Which may take years. With coexistence, you can replace the OS today. Then next month replace one or two apps. etc etc. Pretty soon, you've transitioned completely (or almost so; it's asymptotic) -- which means (a) better penetration by MS's upgraded products, and (b) lots more dough leaving your wallet and going to MS/Adobe/Intuit/etc sooner. This is good for the software companies [tertiary effects like "MS domination == bad" ignored] and good for software users [one wouldn't buy the new apps at all if their perceived value was less than the cost; so obviously the purchaser thinks it was a good]. That was a really good essay. I wish I could remember who wrote it and where I saw it... Now, apply the same logic to autoconf-2.13 and 2.5x. We'd have been THRU this transition completely if the autoconf developers had done the following: 1) spend six months developing 2.14 -- a 2.13-compatible version of autoconf, that provided the additional capability of coexisting with the new feature-branch autoconf (what we call 2.5x). 2) then spend six months NOT adding features to 2.5x, but making sure that it seamlessly could coexist side-by-side with 2.14. Release 2.15, 2.16 as needed while working out these kinks, but always maintain 2.13-compatibility. 3) Spend six more months developing the spiffy new- incompatible features you wanted all along in the 2.5x branch. 4) Spring it on the world and watch everybody install it as soon as they can. What's the danger? They still have 2.1x and can keep using it, but they can also play with the shiny new toy. Mmmm... Toys.... Everbody knows how geeks are with new gadgets. In 30 days, you'd've seen dozens of major packages make the switch. Six months after that, everything important would have switched. Total time elapsed: 24 months. And no bad feelings ("those !@#$!#$ autoconf bastards...") Instead, two years ago they said "Here ya go: autoconf-2.5x. It's been rearchitected internally and we really like it. It doesn't add a whole lot of new features, and it will choke on some files that the old version accepted. But trust us, it does things The Right Way. Never mind that these benefits are invisible to the end-user. Oh yeah -- and you can't easily use it and 2.13 on the same computer thanks to a variety of bad decisions on our part. And the latest automake and libtool releases require that you use this new incompatible autoconf. Have fun." Where are we now? Two years later, we kinda sorta can have coexistence on some platforms, by using 3rd party wrappers, but it still isn't seamless. Some packages have made the switch, others are toying with it, but it's always painful, acrimonious, and slow. Gcc/binutils are still playing at it. Worse, it's slowed autoconf's own development and acceptance, as well as that of automake, libtool, m4... Oh, and it's made MY life harder. :-) -- Chuck [Boy, am I in a rant-y mood lately or what.] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/