[Ffmpeg-devel] [PATCH] Staticising mpeg12data header
Wed Sep 20 21:07:12 CEST 2006
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
> 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.
mru at inprovide.com
More information about the ffmpeg-devel