I want to know about writes.... (Linux Kernel Team - EPIC FAIL)

Yet Linux tells you, in no uncertain terms, to fuck off.

Here's my scenario in a current software project:

• Process W attempts to write X bytes to file Y at offset Z
• My filter examines said request and based on some specific criteria (that some overworked, under-financed system administrator is mandated to enforce) allows or denies such request
• I have no desire to diminish the performance of the host running my software more than is absolutely required - this means that implementing a FUSE solution is bad (userspace->kernelspace->userspace->my software->kernelspace->fs verses userspace->kernelspace->my software->kernelspace continue),

Reading the above, it all looks quite routine. For those of you thinking this, you are unfortunately wrong.

It seems that the Linux kernel team have precisely zero regard for commercial reality. I will happily apologise in the most public arena possible if this is incorrect but the supporting evidence is in my favour:

* Windows has provided this functionality in a standard fashion for 15+ years. Please, please, please don't make me explain why this is a terrible indictment. 

* Other UNIXes have offered this functionality in well-defined ways for a decade

* DOS offered such functionality to user-space applications

* Linux Security Modules offered the "hooks" to make this happen, but LSM was let into the kernel without any regard to multiple users of said functionality - the next step was to remove the API. 

* grsecurity, RSBAC, Dazuko, RedirFS, McAfee, CA, AVG and Trend Micro are all at a stupid disadvantage with regard to your indifference to reality - access control to file system assets is a modern requirement, and Linux is alone in providing no standardised API for these applications to provide such in a standardised, efficient and simple-to-implement fashion. The teams responsible for OSSEC, Osiris and Tripwire curse you in a similar fashion.

Before the more versed of you respond:

* syscall hooking - yes, I'll totally interfere in the kernel's operations by inserting code not at all verified by the OS vendor. And while I'm at it, I'll disable any software taking a similar approach, or forgo any decently weighty contract of my own software being in effect and disable SELinux, AppArmor and so on. Grow up.

* FUSE - sure, let's engage in 5 copies of data instead of 2. Learn to count.

* Kernel patching - without taking away from the work of DazukoFS (Dazuko and RedirFS are precisely worthless for this application), DazukoFS doesn't actually work on any Linux distribution that anyone who isn't planning to upgrade in the next 4 months actually uses or is supported by any application that any business actually cares about other than Samba. As good as DazukoFS is, it may as well not exist at the moment (see http://dazuko.dnsalias.org/wiki/index.php/Dazuko-based_Applications if you don't believe me).

So, in summary, it's easier to implement anything that worries about the specific operations on files cleanly on Windows than it is on Linux. One is an OS that I love, promote at every possible opportunity, performs better on every modern hardware platform under the sun, provides more out of the box functionality and the other is Microsoft Windows.

Sorry Linux Kernel Team - EPIC FAIL.