Sorry, but it's just lies at this point

I'm sorry you feel so much frustration.

> How many of these are packaged by your distribution? Samhain, OSSEC, Integrit, AIDE,
Tripwire (OSS version), Tiger

I did take a quick look at this, though, and it looks like for Debian and Ubuntu the answer
is, all of them except OSSEC.  Additionally, the Tiger package appears to contain extensive
enhancements to let it make use of the dpkg database to better validate installed files.  A
quick google suggests[0] that the hold-up on integrating OSSEC is a combination of manpower,
the fact that the upstream package is garbage (seriously, /var/ossec/etc, /var/ossec/bin?),
and the fact that OSSEC is *not legal to redistribute*, because the authors don't understand
that the GPL and OpenSSL licenses are incompatible.

This is a rather nice example of how expertise in coding does not imply expertise in
distribution.  They're different skill-sets.

I see two changes you might be arguing for.  The first is that upstream authors should
habitually make their own packages.  As we see in the case of OSSEC -- and this is pretty much
the universal opinion of anyone whose dealt with any sort of vendor-produced packages ever --
this is an AWFUL IDEA because a huge percentage of upstream will give you garbage.  So as a
user, I insist on having some technical and legal gatekeeper between upstream and my machine.
In fact, the possibility of getting such a gatekeeper is generally considered to be one of the
major advantages of Linux over Windows.

The other thing you seem to argue is that okay, if we need a gatekeeper, there should still
only be one of them -- systems should be similar enough that once one person has done this
work, everyone can make use of it.  Roughly, this comes down to saying "there should only be
one distribution".  Which, well, I guess I can see the argument... but frankly it doesn't
matter how good the argument is, because as soon as you successfully got things down to one
distribution, some jerk would ignore all your hard work and start another one, and there we go
again.  But maybe it helps to reflect that having multiple distributions also creates a lot of
good to justify the bad -- it creates competition to drive development, it provides space for
many different approaches to be explored (look at e.g. all the different init systems) before
any single one is picked, etc.

Hope that helps.

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361954