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

[Johnny Billquist]

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