martelli@cadlab.sublink.ORG (Alex Martelli) (05/05/91)
rcd@ico.isc.com (Dick Dunn) writes (in comp.arch, re ACE): ... :for OS software that has yet to be written, why did they need to pick two :directions (times two hardware directions gives four?) instead of one? I :may be missing something important, but this aspect of ACE sure looks like :one of those "it's a dessert topping; it's a floor polish" skits. Don't forget they'll support BOTH Dec Turbochannel AND EISA... so, times two again... the bus variation may be the most important of the three, for 3rd party addon-board manufacturers, and for purchasers of vast numbers of machines, who can't really buy machines with different buses if they want to be able to minimize spare parts inventory for the addon cards. I share your perplexity; and I shake my head at the rumor that Dec is going to hand over Ultrix-cum-OSF/1, lock, stock, and barrel, to SCO, to become the base of the ACEy ODT, which Dec will in turn adopt, dropping Ultrix... I hope this last rumor is wildly unfounded??? We're evaluating a centralized NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant to place in such a crucial hub role in our LAN a box from a company who has just decided its system software is better manufactured by somebody else!
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (05/06/91)
In article <816@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes: | I share your perplexity; and I shake my head at the rumor that Dec is going | to hand over Ultrix-cum-OSF/1, lock, stock, and barrel, to SCO, to become | the base of the ACEy ODT, which Dec will in turn adopt, dropping Ultrix... | I hope this last rumor is wildly unfounded??? We're evaluating a centralized | NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant | to place in such a crucial hub role in our LAN a box from a company who has | just decided its system software is better manufactured by somebody else! I think the most likely course is that SCO will start from Mach and go from there. And why shouldn't DEC have someone make their software, when they are having someone (MIPS) make their CPU? -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"
peter@ficc.ferranti.com (peter da silva) (05/06/91)
In article <816@cadlab.sublink.ORG>, martelli@cadlab.sublink.ORG (Alex Martelli) writes: > I hope this last rumor is wildly unfounded??? We're evaluating a centralized > NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant > to place in such a crucial hub role in our LAN a box from a company who has > just decided its system software is better manufactured by somebody else! Given DEC's past problems with system software, I see this as a hopeful sign. After all, you were already getting ready to buy a DEC product with a mostly third-party O/S. Why not make it explicit? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
grr@cbmvax.commodore.com (George Robbins) (05/08/91)
In article <DV3B=4A@xds13.ferranti.com> peter@ficc.ferranti.com (peter da silva) writes: > In article <816@cadlab.sublink.ORG>, martelli@cadlab.sublink.ORG (Alex Martelli) writes: > > I hope this last rumor is wildly unfounded??? We're evaluating a centralized > > NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant > > to place in such a crucial hub role in our LAN a box from a company who has > > just decided its system software is better manufactured by somebody else! > > Given DEC's past problems with system software, I see this as a hopeful sign. DEC's transgressions and omissions pale compared to SCO. Even idiocy like the dump vs super-user thing that recently re-surfaced. Things would be far worse in a multi-party system software environment where the customer service responsibility and the development responsibility are even further separated than present. Now, if DEC would just donate LAT and MIPS support to CSRG, I could punt on the whole mess and run 4.4 BSD (someday). 8-) 8-( -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (05/11/91)
In article <DV3B=4A@xds13.ferranti.com> peter@ficc.ferranti.com (peter da silva) writes: >In article <816@cadlab.sublink.ORG>, martelli@cadlab.sublink.ORG (Alex Martelli) writes: >> I hope this last rumor is wildly unfounded??? We're evaluating a centralized >> NFS server, and DS5500 was looking pretty good, but I would be VERY hesitant >> to place in such a crucial hub role in our LAN a box from a company who has >> just decided its system software is better manufactured by somebody else! >Given DEC's past problems with system software, I see this as a hopeful sign. >After all, you were already getting ready to buy a DEC product with a mostly >third-party O/S. Why not make it explicit? DEC is even reselling 386 PCs manufactured by Radio Shack (and that particular PC is the best computer I've ever seen Radio Shack make) -- /* jallen@ic.sunysb.edu */ /* Amazing */ /* Joe Allen 129.49.12.74 */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
mash@mips.com (John Mashey) (05/21/91)
In article <816@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes: > ... >:for OS software that has yet to be written, why did they need to pick two >:directions (times two hardware directions gives four?) instead of one? I >:may be missing something important, but this aspect of ACE sure looks like >:one of those "it's a dessert topping; it's a floor polish" skits. > >Don't forget they'll support BOTH Dec Turbochannel AND EISA... so, times >two again... the bus variation may be the most important of the three, for >3rd party addon-board manufacturers, and for purchasers of vast numbers of >machines, who can't really buy machines with different buses if they want >to be able to minimize spare parts inventory for the addon cards. This is nonsense. In the PC world: there are XT busses, AT busses, EISA busses, MCA busses. Much of this happened sort of by accident, and a lot of software knows too much about what's there, in gory detail. ACE assumes that ability to hit different price/performance areas, and to evolve, requires a sensible scheme for the inclusion of different busses, (or no bus at all), which after all, is done by most serious computer systems vendors. It is absolutely nuts to think that a bus in widespread use now [EISA, for example] is going to fulfill everybody's needs in 10 years. Hence, the ACE compatibility specifications are structured so that one can have a reasonable shrink-wrapped kernel that doesn't HAVE to know about the I/O bus choice, but still has enough info to be able to boot. This is a lot easier to do when starting from scratch with the experience of the last 10 years.... -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650