Xref: utzoo comp.arch:22517 comp.unix.ultrix:7145 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!hellgate.utah.edu!csn!ub!dsinc!bagate!cbmvax!grr From: grr@cbmvax.commodore.com (George Robbins) Newsgroups: comp.arch,comp.unix.ultrix Subject: Re: ACE, buses, and the future of ultrix Message-ID: <21366@cbmvax.commodore.com> Date: 8 May 91 05:46:23 GMT References: <1991Apr30.191117.4373@vax5.cit.cornell.edu> <32459@usc> <816@cadlab.sublink.ORG> Reply-To: grr@cbmvax.commodore.com (George Robbins) Organization: Commodore, West Chester, PA Lines: 22 In article 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)