[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Måns Rullgård]

Rich Felker <dalias at aerifal.cx> writes:

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

That is still where a big difference between Unix/Linux and Windows
lies.  Linux and the GNU tools give you a lot of features that you
*can* use, should you have a genuine need for them, while you can
simply ignore them otherwise.  In Windows, there are a lot of
complicated things you are *required* to do, even if a simpler
solution would have sufficed.  Look at fork() vs CreateProcess(), or
whatever it's called, for a good example.  Shared library management
is another.

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

I tend to agree with a lot of that.

-- 
M?ns Rullg?rd
mru at inprovide.com