The battle moves on from why pay for an OS to why pay for an application(database)

Huh? You're relying on them?

Some of them probably wouldn't even know what a transaction was, or the
slightest thing about J2EE.

I'm not a J2EE (or Java at all really) developer, but I've always had
the impression that J2EE transaction stuff was all high level container
and component stuff far removed from the JDBC level. Components could
define their own transactional methods, and these filtered up to other
components etc.

I'm not a J2EE developer though - the closest I get is admining JBoss
servers.

J2EE is a very heavyweight bureaucratic overengineered framework with
lots of development overhead. In the Java world there's quite a movement
away from it to lighter frameworks that are quicker to develop with.
J2EE is probably only justified for really really huge projects. 5 yrs
ago though it probably seemed like an improvement over C++ / CORBA stuff

They can be added. The standard permissions while not as flexible or
'rich' are simpler to admin and are usually all that is necessary on
most Unix servers.

Unix has traditionally been used more as an application server than a
file server, as opposed to Netware and NT that started life as mainly
file servers. ACLs are very important for a file server, but not so much
for an app server.

Strange, I would've though the intruder would then try to exploit more
vulnerable services on the inside servers or desktops rather that just
go sniffing around fileshares for files. Once they've rooted some PCs or
servers, ACLs don't really matter and passwords can then be sniffed etc.

After all, most intruders want the machines not the data (unless of
course it is for espionage - pretty rare though).

Yep.