>> The only good thing, to me, about "other unices" is that >> apple had a choice and chose BSD. > >Compatibility/portability (read: standards) is the main reason why Linux >became what it is today. _Do_not_ break this or Linux will lose...
Linux's POSIX compatibility is weak in all kinds of areas. There are dozens of examples of how POSIX conformant code will not work under Linux, and just as many of subtle uses of Linux behaviour that, while conforming to the POSIX API, will not work on other POSIX platforms. Linux got where it is today by being close enough to the standard that porting was easy *enough*, plus 100% open so we could read (and fix) anything even if AT&T didn't bless us. >Btw. OSS follows the original unix idea and POSIX rule of "everything is a >file" very well. It works with open()/read()/write()/close() as the other >devices do. And it's controlled via ioctl() as it should. Unless you want to put the sound drivers into glibc, or you use a POSIX variant where open/read/write/close/ioctl can be handed off to user-space daemons, using open/read/write/close/ioctl *requires* that 100% of an audio API be in the kernel. This is a ridiculous design decision, for many reasons. SGI don't do it on IRIX. BeOS didn't do it. Mac OS X doesn't do it. Windows doesn't do it. Can you guess why? I won't go into the entire callback-related issues that have been illustrated elsewhere in this thread. >Windows is good example of total API mess where there is different API for >all the different twinkles, different error codes, etc. At least in Windows you can enter single thread blocking routine to wait for any kind of event (file descriptor ready, semaphore, message, signal). Under POSIX you can't do this, and you have to use a separate thread for every type of event. How's that for unified API? --p [ jeez: he got me defending windows! time to die? ]
