[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Rich Felker]

On Wed, Sep 20, 2006 at 06:16:56PM +0200, Michel Bardiaux wrote:
> I tend to agree with Rich here. When visibility of exported symbols was 
> only an issue on MS-W platforms, the usual attitude in th 'nix world 
> was: "That's a very bad dynamic linkage model! Off with his head! The 
> Unix model, with a single symbol space and every symbol visible 
> everywhere, is MUCH simpler hence MUCH better".
> 
> Now gcc et al. have introduced visibility control in gcc and ld, and all 
> of a sudden it becomes a good idea!

Indeed, this is exactly what I meant. Damn hypocrites. They criticize
windows ideas as stupid until Linux has them too, then go praising the
same stupid ideas.

And yes in this case it's not _quite_ the same because on Linux it's
optional, but the principle is still quite analogous.

> It's a common enough syndrome. When there was no direct TLS support in 
> Linux pthreads, writing about it only got you 'That would be very bad 
> for performance, because of TLB flushing!' (or the ozone layer, or 
> whatever). Now 2.6 and NPTL *have* direct TLS support with assist from 
> gcc, and wow, now TLS is cool!

I hate TLS too. Yet another GCC extension designed to lock people into
GCC. GNU software is no different than MS in this regard. They keep
adding more and more extensions that no one ever really needed in the
first place, but then because people get used to them and poorly
written software depends on them, everyone feels like they "need" GNU
extensions just like they "need" the latest MS Word.

It's all about inventing complexity for the sake of monopoly, and a
monopoly ruled by a piece of free software is only marginally better
than one ruled by proprietary software. Real software freedom comes
only through plurality -- respect for _simple_ standards and
interoperability. Overly complex standards (which all standards have
the thread of becoming) only serve to reinforce monopolies by making
the standard so difficult to implement that no one but the historical
implementations has a chance to finish it before the standard enters
its next phase of exponential growth.

Rich