This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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. :-)


[Boy, am I in a rant-y mood lately or what.]

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]