The Perfect Computer - 36 bits?
|
From: Nick Maclaren on 29 Mar 2007 08:25 In article <571pauF2a7qasU1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> writes: |> |> > It may not have helped you, but there have been a lot of occasions in |> > which I have needed to know where something might have been updated |> > NOT in the main modules. And there were a zillion reads and loads of |> > the address :-( |> |> VMS has a WATCH facility which lets you monitor reads or writes of given |> system addresses, and will report the places from where they are happening, in |> symbolic form. Yes, that's really a nice thing, sometimes it even helps you to |> diagnose those ugly race conditions. As do many other systems. That can help, but didn't/doesn't help in the cases I am thinking of. Regards, Nick Maclaren.
From: jmfbahciv on 29 Mar 2007 08:17 In article <6meeue.322.ln(a)via.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <eudjec$8qk_001(a)s970.apx1.sbo.ma.dialup.rcn.com>, > <jmfbahciv(a)aol.com> wrote: >>In article <u75cue.3mm2.ln(a)via.reistad.name>, >> Morten Reistad <first(a)last.name> wrote: >>>In article <euauli$8qk_001(a)s961.apx1.sbo.ma.dialup.rcn.com>, >>> <jmfbahciv(a)aol.com> wrote: >>>>In article <crh9ue.mc82.ln(a)via.reistad.name>, >>>> Morten Reistad <first(a)last.name> wrote: >>>>>In article <56qh33F29t3i0U1(a)mid.individual.net>, >>>>>Del Cecchi <cecchinospam(a)us.ibm.com> wrote: >>>>>>Andrew Swallow wrote: >>>>>>> jmfbahciv(a)aol.com wrote: > >>> >>>The trust was by then long gone. They had imploded once before. >> >>It had nothing to do with trust. The signals were sent. It was >>in the plans. The fact that the software still exists is, I believe, >>entirely due to the workers under the covers. Their efforts will >>probably never be recognized nor admired. > >Yes, DEC alunmi has contributed a lot to computing, both in >hardware, software and networking. It has mostly been despite >DEC management, not because of it. > >>>>>Snake oil, may 17th and all that. >>>>> >>>>>We keep harping on this. I have wondered why. I think this is a discussion >>>>>of today's dangers by proxy. >>>> >>>>Yes. It also has to do with excellence. Doing a job well does not >>>>guarantee longevity; there will always be somebody or something >>>>that will destroy it. >>> >>>It means you cannot rely on external forces from your organisation to >>>keep excellence. You must have control. >> >>It means that you have to have some way to get rid of those who >>are in control and destroying the company. We never figured out >>how. > >I was looking from the other side. If your software is critically >important for your business you must be prepared to reimplement all >the necessities for that software from other vendors. You are in error to even make this IF. Software was viewed as the source of the problems that DEC was having. Think about this one. It is key to all that happened. > >>>>>The important lesson from the events is that you should never, ever >>>>>have a single source for the equipment that runs your business critical >>>>>systems. Even if it is DEC, IBM, HP or a similar blue-chip giant. >>>> >>>>Please, please, please include software in this. You also have >>>>to consider the software. The computer biz is depending on essentially >>>>two pots for software; one of them can be expected to screw you up >>>>and the other still needs some evolution. >>> >>>Software is a part of it, but software goes nowhere without a >>>system to run it on. This is also why later software have been so >>>extensively based on portable compilers. >>> >>>Bliss software was dead May 18th 1983. >> >>BLISS was always dead. It was a horrible mess; I always thought >>this was due to having a university implementing it without >>the constraints of constant feedback from varied customer usages. > >That was a bait specifically for you. ;-> One of these days, I'm going to think of a way to punish you. It will involve creating a distribution package of software that is all written in BLISS. :-))) One of the problems in DEC was that Bliss had not be deleted from all disk packes and CMU alumni believed that it could be used for all coding. My personal opinion is that the delays of DECnet could be tied to the Bliss edict. It added thousands of manhours to any project. > >>>>>Because even DEC folded on us. Not as spectacularly as International >>>>>Harvester a century before, but enough to shake us all. >>>>> >>>>>DEC was a company with a reputation far ahead of today's HP or Microsoft. >>>>>Somewhat like a reconsituted IBM of today, or Intel, or Apple. These >>>>companies >>>>>are/were blue-chip giants that constitute a core of IT technology. >>>>> >>>>>But the lesson is that if DEC can implode, so can they. >>>> >>>>People keep assuming that it was a goal to stay in business. It >>>>was not from all the evidence I saw. >>> >>>If the moves DEC management did were done without a goal of a >>>going concern the managers would have been guilty of several crimes. >>> >>>The presumption of a going concern is part of all bookkeeping and >>>exchange listing. You must be very careful about stating what parts >>>of the company you plan to liquidate or wind down. >> >>It was getting stated. All those parts that were sold off were part >>preparing for the Compaq deal; at least that was my assumption. >>Note that I was not working during that time and was watching >>from the outside in. All the clues were in the Wall Street Journal >>from their first sale of bonds to the sales of the sites that >>were profitable. > >Selling the company is not contrary to a going concern, the >buyer would want it to continue. So dressing up for a sale is not >contrary to business practice. But the buyer was not interested in development at all. That was the irony because DEC excellence in its help desk was due 100% to having the developers a phone call away and teaching them before the new releases were shipped. > >Planning to terminate major parts of a company _are_ contrary >to accounting practice, and must be clearly flagged in the reports. They didnt terminate them; they sold them. > >>>>>The lesser ones all imploded. Wang, Prime, Norsk Data, ICL, Honeywell, >>>>>NCR, Siemens, DG and more all imploded in that decade. In our guts, >>>>>we kind of expected somesuch to happen. It was DEC that shook us. >>>>> >>>>>Today we wouldn't be much shaken if HP/Compaq, Dell, Lenovo, TCI, Via, Sun, >>>>>or even AMD implodes. It will be momentarily painful for us as customers, >>>>>but we will migrate elsewhere. Workers and PHB's can follow the business >>>>>that moves without too much trouble. >>>>> >>>>>It is when outfits like Apple, IBM, Intel or Microsoft folds that we >>>>>are shaken, all of us. >>>>> >>>>>The lesson from DEC is that it can happen. >>>>> >>>>>Always have a Plan B. >>>> >>>>And plans C, D, E, F, ...., Z, omega. >>>> >>>>You're missing software aspect in this post :-). >>> >>>Software is just a necessary part of the systems. >> >>No. I'm not writing clearly again :-(. Software is invisible. >>You cannot detect when something is wrong until _after_ the >>event. In a lot of cases (I've seen them) there isn't any >>going back to just before the mess began. For instance, >>losing sources. > >In these scenarios the software is part of a larger system. >Knowledge of the incantations to make a piece of hardware >obey, as well as the production line of that hardware, is >just as important as the software. And all are worthless if >the production environment disappears. > >>>>The reason, I think, that this thread drift has happened is >>>>because of an assumption that, if the PDP-10 was "no good", >>>>one shouldn't make a new CPU architecture that includes >>>>it's good ideas. What people refuse to believe is that >>>>a company would shutdown a product line that made money >>>>and was wanted^Wdemanded by its customers. It happened. >>> >>>We see it happen again with MS Vista. Those customers don't >>>have a Plan B, and will be just as burnt as we were. >>> >>>But I have told them for a decade that it will happen. >> >>I still haven't heard much about this one. The gamers aren't >>bitching. > >Lastest pc press blurbs. Vista only runs around 80 of 150 >identified critical XP applications. So can we make a reasonable assumption that the load tests involved all games and not critical apps? /BAH
From: Jan Vorbrüggen on 29 Mar 2007 08:29 > Real-world, but your second question is very relevant. The VAX was > relatively constant in performance between workloads, but the Alpha > varied by an incredible factor (ten or more, on practical workloads). Yes, and that is a very valid comment. I think there was some COBOL program where the VAX was faster than the Alpha, but I don't remember whether it was translated or recompiled (the latter case would be even more surprising). I think the factor of 2 came from the benchmark workload that DEC used to define "VAX MIPS", so it was actually geared towards the VAX. On anything to do with floating point, the Alpha was much faster. Jan
From: Jan Vorbrüggen on 29 Mar 2007 08:31 > Not having source *or* fiche made me very nervous. Ah yes, and now think about all those business- and safety-critical customers of the Microsoft operating systems... Jan PS: For those OSes, quite likely even having the source wouldn't help you much...
From: Jan Vorbrüggen on 29 Mar 2007 08:35
[Good and fair, IMO, description of the VAX->Alpha and Alpha->Itanium transitions] > About the only good thing that they learned from DEC was that Alpha and Itanium > have the same VMS codebase. However, that was only possible because of the earlier VAX-to-Alpha port, which had made sure that the VAXism-infested VAX/VMS codebase was transformed into something much more portable. Also, the concepts on how to handle the 32- to 64-bit transition gracefully had already been validated. Jan |