Choosing between portability and innovation

What's needed is a kernel/user space cooperation to develop good useful APIs, and make them easy to use for applications that can be later emulated on the BSDs with a different underlying implementation.

If it proves very difficult to write another implementation, it probably suggests that the API is a crock of **** and won't stand the test of time, and the ever onward march of progress. But be an ossified handicap to future progress. Good abstractions are things that can be built upon.

1) Reliable Signals
2) Virtual Memory
3) Shared Memory / Semaphores
4) Streams
5) FIFO's
6) TERMCAP & curses(3) (re-implemented by ATT as termlib with enhancements)

Given the widely perceived fragmentation of Linux distros, with tweaked features sets, for instance deb v rpm, it's naive to think you can write without regard to portability. Even with FHS, applications end up having to account for cosmetic differences between distros.

Portabiity is a requirement, otherwise you prevent change and innovation, and trust me you would not get much done stuck on Version 6 UNIX.

Look at the problems discussed with move to IPv6 last month!!! Portability allows the whole FOSS ecosystem to evolve and adapt.

If there's better documentation now I'd love to know about it.

However, only to a point, because one ends up with ifdefs strewn through the code, or internal abstraction layers to cover the differences between supported platforms of varying ages. This does not improve the quality, readability, nor maintainability of the code indefinitely.

Surely one should employ caution when using new abstractions, and clearly define one's target audience. And be open to clean patches that make code portable (if they come with a maintenance commitment).

But one can't place the entire burden of this on the main author or core team, which also has limited time and resources. Someone else can contribute compatibility libraries or port the new APIs to other platforms - it's open source, after all. ;-)

And quite frankly, a number of POSIX APIs suck. Signals are one such example, IPC is another, and let us not even get started about the steaming pile that is threads. Insisting that one sticks with these forever is not really in the interest of software quality. They are hard to get right, easy to get wrong, and have weird interactions; not exactly an environment in which quality flourishes.

If signalfd() et al for example really are so cool (and they look quite clean to me), maybe it is time they get adopted by other platforms and/or POSIX.

The pattern keeps repeating itself- those who are developing new frameworks where portability is an afterthought tend to have tunnel vision and the resulting design is awful. Sure, the software gets written, but it's only to be replaced by another harebrained API a couple years down the road. This is what gets us the stupid churn which is one of the prime reasons the Linux desktop hasn't really gotten very far in the past decade. I'll give two examples:

If people had sat down and said "what should a modern Unix audio subsystem look like? What are the proper abstractions and interfaces regardless of what kernel is under the hood?" we wouldn't have had the awful trainwreck which is ALSA and half of the complications we have today would have been averted.

The only people doing 3d work on Linux who don't treat BSD as a third-class citizen are the nV developers. Not coincidentally, they're the only ones who have an architecture which works well enough to be consistently competitive with Windows. The DRM/Mesa stack has seen a dozen new acronyms come and go in the past few years, without much real improvement for end users. Frameworks have often been designed for Intel integrated graphics on Linux and only bludgeoned into working for other companies' hardware and - only recently- for other kernels. Even for Intel on Linux the result is crap.