ETXTBSY

[John Esak]

>From SCO: (whoever that is...)

> In any case, though, it seems to me the first question to be answered
> is, "is there a strong case for restoring ETXTBSY behavior, and, if so,
> what is it?".
>
> --
> JP

Truly, my first response to this "first" question is an angry one. How else
could someone respond to a statement as clueless as this? I want to say if
you don't know the answer  you shouldn't be allowed to make *any* design
decisions on a product as widely used as SCO operating systems. And not that
I feel the need to educate you on such matters, but it deals with
expectations, reliability, backward compatibility and... need I go on. These
things are and should be priority number one for any software, let alone an
entire operating system developer... and if you don't know this... you
shouldn't be asking or answering questions in the "first" place.

My second response is to echo the sentiments of many/most who have joined in
this thread. For example.

--------------- Original Message ---------------
At 07:02P Wed Oct 26 2005, Jay R. Ashworth wrote:

[...]
> If Unixware *allows* pure-text binaries in the traditional sense, and
> does *not* trap for overwriting of them, then it is irretrievably
> broken.  [...]

It all boils down to the mis-labeling of SCO OpenServer 6.0 as *that*
instead of what it obviously truly is:

 SCO <Something-like-Unixware-with-parts-of-OpenServer" 1.0

This whole product naming was obviously a ploy to pull in the vast majority
of the SCO user base, which was Xenix and later OpenServer founded.  The
Unixware product gathered no following, so why not exploit the base that you
*do* have, and foist it on them as an upgrade? Indeed, why not.

I couldn't be happier with some of the VM functionality... running SCO
OpenServer 6.0 as a guest o/s under Windows 2003 Server is a real plus for
us.  However, to gain new technology only at the loss of other expected
functionality is not impressing me much.

John Esak