Quoting Mark Rousell (mark.rousell@???):

> If you want and/or need full support and recompense for failure, then
> by all means pay for a service provider to provide this. Red Hat
> Enterprise Linux is available, for example, and there are many
> consultancies whom you can pay to configure and run things for you.
> But even then, their liability towards you will tend to be
> contractually limited.

Well put. Reminds me of one of the things I said in the Linux User
Group HOWTO:

[U]nderstand that the notion of "use value" for software is quite
foreign to most people -- the notion of measuring software's value by
what you can do with it. The habit of valuing everything at
_acquisition cost_ is deeply ingrained. In 1996, I heard a young
fellow from Caldera Systems speak at a Berkeley, California LUG
about the origins of Caldera Network Desktop (the initial name of
their GNU/Linux distribution) in Novell, Inc.'s "Corsair" desktop-OS
project: In surveying corporate CEOs and CTOs, they found corporate
officers to be inherently unhappy with anything they could get for
free. So, Caldera offered them a solution -- by charging money.

During my long period of operating a LAN/WAN consultancy, I developed a
saying that 'If the clients aren't listening, it probably means I'm not
charging enough.' Around 1996, about the same time the earnest-looking
fellow from Caldera Systems was giving that talk about CalLUG, I had a
client (long ago wound up in bankruptcy, so I don't mind talking in
public about this) that had basic-rate ISDN links between its four
branch offices and its main office in Walnut Creek, California where I
was doing consulting work. I noticed that, about once a week, they had
network storms of bad-route propagation, which I could temporarily abate
by re-training the routers using ping and traceroute. Management asked
if I knew how to fix the problem, and I said 'Yes, certainly.'

'You are using Ascend Pipeline 50 routers for the nailed-up connection
between the offices, and using Routing Information Protocol v2, aka RIP,
to automatically maintain routing tables. The problem is, RIP doesn't
scale. When you had only Portland and Costa Mesa branch offices, it was
probably reliable. Now that you added Sacramento and Phoenix, routing
is becoming unstable.' 'What do you recommend?' 'This [passes out
copies of a printed sheet with a five-line routing table for Walnut
Creek, and a one-line routing table for each of the other offices].
I can enter these static routing instructions into the Pipeline 50s
right away, and it'll completely fix your problem.' 'But that would
mean we'd need to update the routing instructions if we ever opened
or closed branch offices.' 'Yes, that's true.' 'Is there any way
we can retain the advantage of automatic routing?' 'Yes, but only
by replacing all the Pipeline 50s with a better ISDN router that does
Open Shortest Path First aka OSPF.' 'We'll have to think this over.'
'OK.'

Management hired an expensive local consulting firm to 'study the
proolem', producing weeks later a 40-page spiral-bound report with lots
of graphs, which, if you boiled it down to actual content said 'RIPv2
doesn't scale. Either use static routes or switch to replacement
routers that doe OSPF.'

If I'd had a higher hourly fee, and threw in some graphs and
bureaucratically padded reports, they might have listened the first
time. ;->