cygwin patches integrating back into standard gnu

[Charles Wilson]

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/