On Sat, 2007-09-08 at 12:27 -0600, Frank Cox wrote: > On Sat, 08 Sep 2007 13:17:11 -0500 > Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > > > Those are great for server apps that were feature complete ages ago but > > not so great for desktops apps receiving a lot of current attention. By > > next year the Firefox, OpenOffice, Evolution, etc. versions they include > > will be way, way out of date instead of just slightly outdated like they > > are now. Does firefox 1.5 sound current to anyone here? Would you want > > to be stuck with it until the next Centos release? > > You are asking for something that is logically inconsistent. > > 1. You want absolutely stable software. > > 2. You want the latest-and-greatest software. > > Though you try to sound like you are an "old hand" with computers and system > administration, this demand makes it appear that you don't have the experience > that you are claiming to have. > > By definition, the latest-and-greatest software is not going to be rock-solid > stable. That's why it's called "cutting edge" -- you can sometimes get cut > when you use it. > > You must make a choice here. Do you want stable software that doesn't change > over the longer term? Or do you want the latest new toys and gadgets to play > with. > > You have failed to make that choice, and want both. Sorry. It just doesn't > work that way. "I demand a dog, but it has to look exactly like a cat." > > No. You can't have it. > > I realize that you are probably disappointed by this, but it's simply the > nature of the way that software development works in real life. > Hi, Frank, I can't dispute that this is how software has developed. But that still doesn't make it right. Would you drive over a bridge that had a 10% or higher chance of failure? Or ride in an elevator with similar risks? Of course not. Standards were developed that governed how those things are designed based upon tragic failures. Yet software engineering seems dead set on avoiding the issues surrounding the effective standardization that makes this possible. IEEE and ACM both have committees on software reliability, yet I don't know many engineers who even know about the committees, much less read their proceedings or make any attempt to discover what is known already about software reliability, and how to incorporate it into their work. I am speaking from experience with engineers over 30 years or so, not with people in just desktop applications, but others as well. In my experience the only ones I met who tackled these subjects rigorously were in military or aerospace and some health and biosystems. I don't pretend to understand why, but that is my experience. I hope that this anecdotal situation is just that, and not industry prevalent, because software is increasingly responsible for our safety and protection. As such it should be rigorous. And while it may be defensible to say that Windows and Linux as we know them, are not being used in these applications, some people are beginning to tout these OS's for those applications. Reliability is not a luxury when lives are at stake. Protection from hacking is the same. But also base system capability in terms of reliability day in day out, year after year, is essential in safety and health applications. Things like monitors, defibrillators, emergency monitoring equipment, stoplight control, and aircraft systems to name a few of the more obvious ones, but how about antilock bakes, ignition control systems, home security systems, police response systems, 911 systems, and other public safety stuff. Your own telephone which may save you or a loved ones life. Worse, such reliability must be built in, designed in, and maintained as the standard. Aftermarket doesn't work as the many forms of virus protection for windows shows us. I'm not debating here, just pointing out that reliability is an essential part of the design process. And yes, I do understand the position of Fedora in the process, and I am glad to be here and be part of it. Thanks for reading. I hope my points were not flamers, but thought provoking. Regards, Les H
