[Talk] Re: [Linux-aus] SCO position, rationale and AUUG

[Greg 'groggy' Lehey]

On Friday, 23 May 2003 at 13:15:41 +1000, Chris Samuel wrote:
> On Thursday 22 May 2003 6:35 pm, Greg 'groggy' Lehey wrote:
>> On Thursday, 22 May 2003 at 17:34:56 +1000, Chris Samuel wrote:
>
> My undertstanding from the court document, is that IBM mis-used the source
> code from their UNIX license (originally from AT&T) and from Project
> Monterey. It seems to boil down to:
>
> 	the improper extraction, use, and dissemination of SCO'S UNIX
> 	source code and libraries, and unauthorized misuse of UNIX methods,
> 	concepts, and know-how
>
> from paragraph 96 of the complaint.
>
> SCO's case isn't helped by the fact that they explicitly mention that IBM's
> OmniPrint services (para. 91 & 92) and JFS (para 92) - both of which (IBM
> says) were ported to Linux from the OS/2 codebase, not the AIX
> codebase.

Indeed.

> Mind you, they also quote Robert LeBlanc saying "We're willing to
> open source any part of AIX that the Linux community considers
> valuable.  We have open-sourced the journal filesystem, print driver
> for the Omniprint." which seems to contradict what IBM say about the
> source of JFS & OmniPrint.

Yes.  IBM's right, of course.  The JFS that IBM released was
internally known as JFS 2; it's a greatly improved version of the AIX
JFS ("JFS 1").  While at IBM, I wrote a JFS 1 file system for Linux.
It's clear from what little I saw of it that JFS 1 was derived from
FFS (BSD).  Despite the fact that it wasn't original UNIX source code,
and despite the fact that I was an IBM employee, I was not allowed to
see the AIX code.  If I had been allowed, I wouldn't have dreamed of
copying it: I just wanted to understand how it worked.  For example, a
JFS 1 inode only has space for on indirect block pointer.  It turns
out that if the file is 16 MB in size or less, it points to a single
indirect block; if the size is greater, it points to the double
indirect block.  That would have been so much easier to understand if
I had been allowed to see the source.

>> But yes, the old SCO UNIX, now called Open Deathtrap or Open Server,
>> is based on System V.3.2.  I have a complete set of the ODT software
>> here.
>
> I had the misfortune to have it as one of the over a dozen UNIX variants on a
> compiler development network I was jointly managing in 1994. It was almost
> (but not quite) the worst out of all of them. It was the only one that didn't
> implement symbolic links for a start. :-(

That was more common earlier on.  Symbolic links were one of the
things that System V.4 imported from BSD with UFS.

>> They did it in a completely different way from System V.4.2,
>> the SMP version of System V (not to be confused with System V.4.2,
>> also known as UnixWare).
>
> OK - now I'm confused! I thought that the MP version was SVR4.2 MP ?

Why should you be left out? :-) But you could be right.  I've heard
people claim that SVR4.2 was the multiprocessor version of SVR4, and
others say that it was the desktop version.  It's possible that
neither of them knew the complete functionality.

>> One of the problems SCO (the old one) had was that, although their
>> product was archaic and not real UNIX, it was relatively easy to use.
>> It didn't have as many of the sharp edges that many commercial UNIXes
>> still have (not counting compatibility problems with System V, of
>> course).  That's why OpenDesktop was based on XENIX, and why it's
>> still a System V.3.2 base.  Even UnixWare, a much more modern system,
>> had difficulties keeping up.  There are a number of loyal SCO users
>> out there even today.
>
> I'm afraid I was too badly traumatised by my experience with SCO in 94,95 to
> ever consider it anything like a reasonable OS. Even the HP-SUX 7 boxes we
> had weren't that bad.

By then the stuff was *completely* out of date.  I used SVR[23] in the
late 80s and early 90s, and by comparison XENIX had some nice
features.  It was still a pig to install.

Greg
--
See complete headers for address and phone numbers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.auug.org.au/pipermail/talk/attachments/20030523/fbb8e006/attachment.pgp>