[Info-vax] Current VMS engineering quality, was: Re: What's VMS up to these

[David Froble]

Richard B. Gilbert wrote:
> On 3/17/2012 6:07 PM, Johnny Billquist wrote:
>> On 2012-03-17 14.53, Richard B. Gilbert wrote:
>>> On 3/17/2012 5:03 PM, Nomen Nescio wrote:
>>>> glen herrmannsfeldt<gah at ugcs.caltech.edu> wrote:
>>>>
>>>>> Fritz Wuehler<fritz at spamexpire-201203.rodent.frell.theremailer.net>
>>>>> wrote:
>>>>>> Johnny Billquist<bqt at softjar.se> wrote:
>>>>>
>>>>>>> 2. Unix distributed networks using ethernet and shared disks is not
>>>>>>> robust at all. You must be totally uninformed if you claim this. 
>>>>>>> Have
>>>>>>> you ever used a machine with an NFS root? Any time the server
>>>>>>> stopped,
>>>>>>> rebooted, or whatever, all clients *freeze*. Not even rebooting,
>>>>>>> unless
>>>>>>> you press the power switch. You just sit there waiting for the NFS
>>>>>>> server to wake up again.
>>>>>
>>>>>> Correct. This just happened to me (facepalm) today on a modern Linux
>>>>>> system
>>>>>> 2.6.29.something kernel. I didn't think and took my NFS box offline
>>>>>> and when
>>>>>> my Linux client couldn't get to the mounted share
>>>>>> ..........................
>>>>>
>>>>>> Solution: reboot NFS box. Stupid, stupid, stupid. Can't the UNIX
>>>>>> idiots
>>>>>> *ever* do anything correctly?
>>>>>
>>>>> If you don't like it, use a soft mount, otherwise that is considered
>>>>> correct.
>>>>>
>>>>> If you are writing to a disk, and the disk doesn't respond fast 
>>>>> enough,
>>>>> you don't normally expect the system to just throw away the data you
>>>>> thought you wrote, do you?
>>>>
>>>> I don't think excuses for bad design are going to help. The answer 
>>>> is to
>>>> time out the request if the NFS server doesn't respond and then 
>>>> force an
>>>> unmount, thereby freeing the client system. Where is the deadman
>>>> switch in
>>>> NFS? The only answer is rebooting the client or server, you get the 
>>>> same
>>>> data loss so what's the practical benefit of your data loss analysis?
>>>> Either
>>>> the server has to come up or you lose data, *in their shitty design*.
>>>>
>>>> There should be a two phase commit to make sure the server throws away
>>>> any
>>>> data and the client doesn't consider it committed. IBM can do this 
>>>> stuff
>>>> correctly, UNIX can't. UNIX and NFS are broken, this is just one of a
>>>> million stupid UNIX non-designs.
>>>>
>>>>> Why would you expect that in the case of an NFS disk?
>>>>>
>>>>> As previously mentioned, the result is data loss.
>>>>
>>>> Two phase commit. Don't depend on clients and servers to always get
>>>> along,
>>>> plan for the times they don't. Don't lose data. Don't hang a client
>>>> machine. It's all basic, obvious stuff for a serious OS. UNIX needs
>>>> work,
>>>> lots and lots of work.
>>>>
>>>
>>> Remember, Unix was written by students at Berkely. They wrote it to meet
>>> *their needs*. If your needs were not considered, feel free to fix it
>>> yourself; the sources are available. Just about everyone did
>>> just that! Most, if not all, modern Unix Systems have some "Berkeley" in
>>> their ancestry!
>>
>> Well, not really, but your point is valid anyway. Unix was written at
>> Bell labs, to meet *their* needs. It was then modified by students at
>> Berkely, to meet their needs/do research.
>>
>> Johnny
> 
> Well, lets say that UNIX as we now know it was due in large part, to the 
> Comp Sci, students at Berkely.  It's thanks to them we are not writing 
> IBM JCL!
> 
> 

I would not agree with the JCL part.  Before Unix was an idea, I was happily working with 
RSTS/E.  Served me well until the VAX was introduced.

DEC had a number of operating systems back in the day ....