Hello (again) from Gregg C Levine I have stayed out of this argument or even a discussion because I do know that my opinions would be more along the lines of David's statements. Thank you David for stating exactly what I would have stated.
Yes, I have read his book on the box. It happens I knew two such machines personally; they had some interesting personal quirks that reminded me of two people I also knew at that same shop. It also happens that I also knew two of their predecessors, at much the same shop; it also happens that the same two people worked there. One of them happens to be my father. Now before this evolves into a personal reminiscence, please realize that we are parked in the cutting edge of software development here. As for Linux distributed versions here, I in fact run a released number dot zero, version, and it works reasonably well. UML has one big problem I will state in closing, it is an experimenter's playground. That is why it won't play well on a S/390 type setup. But that's all I will say. Now can we close this, before we resort to other equally unpleasant things? ------------------- Gregg C Levine [EMAIL PROTECTED] ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."� Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > David Andrews > Sent: Friday, September 26, 2003 11:51 AM > To: [EMAIL PROTECTED] > Subject: [LINUX-390] OT: 0.x versions in production (was: UML or Linux on > z/VM) > > On Fri, 2003-09-26 at 03:46, Giorgio Bellussi wrote: > > do you really want a production environment based on an 0.x product? > > Short answer: why not? > > Long answer: this rhetorical (and rather imprecise) question irritates > me. Please excuse me as I vent a little. > > You might as well ask if one really wants a "production environment" > based on a wintel platform. Or a non-raid disk. Or a non-ECC memory > subsystem. Or a power supply not backed by generator. Or on machinery > not configured for fully redundant failover, with geographic > separation. Or a bare-bones DBMS that isn't ACID compliant. Or a > remote network that isn't diversely routed. Or a security mechanism > that isn't audited frequently. Or a nonexistant or easily circumvented > change management regimen. > > These are all value judgments, and depend on your local definition of a > "production environment". A production application could be as simple > as webifying call detail records provided by your PBX. At the other end > of the spectrum you could be launching a two billion dollar orbiter. > (I'm guessing you fall somewhere between these extremes.) > > Have you ever read _The Soul of a New Machine_ by Tracy Kidder? It > chronicles the creation of Data General's "Eclipse" line of computers, > the conflicts among management, marketing and engineering, and the > tradeoffs and compromises that were necessary to bring the project to > completion. The principal engineer, Tom West, was quoted as admitting: > > "Not everything worth doing is worth doing right." > > My personal blog and mail server are production applications - at least > for *me* - running on a P-II system with SCSI disk, ECC memory and some > carefully chosen beta software. A community theatre group that I > support keeps a production web server - also a P-II system - which had > an uptime of 611 consecutive days before being relocated. It also runs > some carefully chosen beta software. > > Over the years in my professional mainframer life I have participated in > a number of beta programs for well-known manufacturers, and have > committed "production" to many of those products well before they became > generally available to the public with version 1.0 stickers. Of course, > we only did this after careful evaluation and due consideration, and not > all beta projects made the cut. > > The point is that whether your "production" system is a personal blog or > a realtime warehouse management system, you are obligated to choose > components according to their observed performance and your > requirements, always being mindful of Tom West's advice: you don't need > a Mack truck to bring home groceries. > > Do not trust version numbers. Version numbers are thin fiction. I've > seen crappy beta software, and great beta software. I've seen crappy > and great release-level software too. There is fundamentally NO > DIFFERENCE between beta code and products with 1.x version numbers. > > Version numbers lie. > > You do yourself and your organization a disservice by arbitrarily > dismissing 0.x software. You might as well avoid odd-numbered releases > (which advice I've heard from ignorant but otherwise well meaning > people). Another silly rule-of-thumb is that you should avoid release > numbers ending in zero. Some people like to wait for the second formal > release of a product before they'll look at it, and some others wait for > a year (or some other magical unit of time) after GA to allow a product > time to "settle down". > > This is either lazy or superstitious, but it's not good business. If > you rely solely on marketing people's version numbers to decide whether > a product is suitable for use in your application -- well, you must have > a pretty easy job. > > -- > David "switching to decaf now" Andrews > A. Duda and Sons, Inc. > [EMAIL PROTECTED]
