This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: cygwin patches integrating back into standard gnu
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/