-platform linux-g++-objprelink still useful?

[Adriaan de Groot]

On Sun, 18 May 2003, Cristian Tibirna wrote:
> On Sunday, 18 May 2003 13:01, Neil Stevens wrote:
> > Can someone explain to me why slightly old free systems are treated with
> > more hostility than any non-free tools?  People never seem this eager to
> > remove all traces of support for non-free systems.  Why remove what was,
> > not too long ago, the best free stuff available?
>
> Possible explanations:
> 1) Help people use the new technologies (or new versions of the old
> technology) instead of the old one, as the new ones offer more
> stability/quality/performance

"I'm sorry, you have last week's kernel, which is no longer supported.
Please upgrade." KDE has a long history of supporting a wide variety of
platforms. That means not just the most recent shiny RH release, but also
last month's, and - heaven forbid - a Linux release from a year ago. This
means supporting gcc 2.95.3 for those platforms (FreeBSD 4.x comes to
mind) that still use that. This means not requiring CVS HEAD off of
flex.Sourceforge.net to compile .l files in KDE (separate issue, resolved
amicably).

Pitching out support for last month's platform isn't "helping people
transition", it's leaving them out in the cold and/or _forcing_ them to
upgrade.

> 2) Cleanup of a code that, being freely developed, shouldn't become more
> difficult to maintain than strictly necessary (in my book, needing ifdefs for
> platforms/features/configs is plain cruelty)

Please explain this to the developers of applications involving CDROMs,
where no two OSses KDEsupports have even remotely similar APIs (well, I
supposed "ioctl" is "remotely similar", but that's it).

> Dunno if any of this applies to the case that made you ask the question,
> but I hope you find these to be valid generic answers.

They sound like the kind of answers that are valid for people with
unlimited bandwidth and no need of guaranteed stability for their systems.
People with expensive dialup, and corporate responsibilities wrt. the
testing and integration of every upgrade on their systems may not be quite
so pleased.

-- 
 Adriaan de Groot    adridg at cs.kun.nl     Kamer A6020     024-3652272
GPG Key Fingerprint 934E 31AA 80A7 723F 54F9  50ED 76AC EE01 FEA2 A3FE
               http://www.cs.kun.nl/~adridg/research/