[FFmpeg-devel] libossupport status

François Revol revol
Sat Dec 29 02:35:55 CET 2007

> > 
> > ffmpeg is actually the only project I know with members insisting 
> > on 
> > porting OSes to the application...
> OSs as well as applications should support standards (POSIX / ISO C)
> its a matter of O(n) vs. O(n^2)
> porting 100 OSs and 100 applications to POSIX is 100+100=200 things 
> to port
> porting 100 apps to 100 OSs is 100*100=10000 things to port
> also very few of the 100 apps will be ported to obscure OSs
> its very simple: fix your OS to support POSIX or watch with your own
> eyes how evolution works

That's why Haiku supports mmap(), poll() and others, and will have PRI* 

if I don't forget to add them.
Still it's not a reason to rigidly reject others.
That's called segregation, or by other names in other circles.
Standards are meant to be exceeded.
But sometimes you don't want to trade a design because it's cleaner or 
whatever just to follow a standard.
That'd make everything sterile and limit technodiversity.

Just like with this return -EFOO thing. It's an Unixism that should die 
IMO, and having error codes negative so you don't forget to negate it 
somewhere is a cleaner design IMO. Plus Haiku can't change that because 
it has to keep compatibility.
There we can't follow the standard (but that's also the standard's 
fault because they changed their mind mid-way and I suspect Be got 
stuck before they did, so in this case it's the standard that is 

Besides I won't call recompiling a POSIX-only app on another POSIX OS 
there's more to that.
Using native features to make the platform distinct is what makes it 
That's where standards help getting a straight first stage port easily 
before adding native features.
For example ffmpeg can compile on a POSIX platform that doesn't support 
pthread (that's also why parts of the specs are optional!), and either 
add native threading, or wait until pthread is implemented.
(Haiku has pthreads mostly already)

I'll stop as I know the ones who should be convinced have their opinion 
a read-only.

More information about the ffmpeg-devel mailing list