Quoting Mark Rousell (mark.rous...@signal100.com): > 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. ;-> _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
