Proof SCO Knew IBM Was Involved in Linux From 1998 Onward

 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements UNIX and Linux RSS News Proof SCO Knew IBM Was Involved in Linux From 1998 Onward
# 1  
Old 08-23-2010
Proof SCO Knew IBM Was Involved in Linux From 1998 Onward

Look what I just found, SCO's Partners page from 2002, on Internet Archive, and lo and behold, it provides proof positive that SCO, then calling itself Caldera, knew that IBM was involved with Linux as far back as 1998. That's the year Santa Cruz and IBM signed the agreement regarding Project Monterey, executed in October of 1998. No one, therefore, Santa Cruz or Caldera, had any reason to be in the dark about IBM's Linux activities while IBM was also working on Project Monterey.
Now that the old caldera.com pages are on Internet Archive again, thanks to SCO selling off the domain name, many interesting things are surfacing, and we find out why SCO tried to hide them for so long. They should have waited a little bit longer.

More...
Login or Register to Ask a Question

Previous Thread | Next Thread

3 More Discussions You Might Find Interesting

1. SCO

Sco 5.0.7 on ibm server, no floppy drive.

I cannot install sco on this particular ibm server because sco cannot find the raid controller and thefore the logical drive. I have a floppy disk that I use in other machines when boot: shows on the screen. I usually type restart link=ad320 and it works but this time i have no floppy drive. ... (1 Reply)
Discussion started by: iNetForce
1 Replies

2. SCO

Install SCO Openserver 6.0.0 on an IBM x3500 7977E6U

Even though IBM states that the x3500 server is Openserver 6.x compatible, it is still a bit of a trick to install SCO Openserver 6 to the machine because the standard method of installing the BTLD required to install the OS requires that the driver be written to a floppy which doesn't exist on... (3 Replies)
Discussion started by: qkrenge
3 Replies

3. News, Links, Events and Announcements

SCO sues IBM

http://www.sco.com/scosource/SCOFilesComplaintAgainstIBM.html in my opinion, there is a simple solution to this, a large company, like IBM, should buy the rights from SCO, and then make their rights to UNIX freely available. could they do something likethat? could they even change the license... (6 Replies)
Discussion started by: norsk hedensk
6 Replies
Login or Register to Ask a Question
UBT(4)							   BSD Kernel Interfaces Manual 						    UBT(4)

NAME
ubt -- USB Bluetooth driver SYNOPSIS
ubt* at uhub? port ? configuration ? interface ? DESCRIPTION
The ubt driver provides support for USB Bluetooth dongles to the Bluetooth protocol stack. USB Bluetooth dongles provide two interfaces, both of which the ubt driver claims. The second interface is used for Isochronous data and will have several alternate configurations regarding bandwidth consumption, which can be set using the hw.ubtN.config sysctl(8) variable. The number of alternate configurations is indicated by the value in the hw.ubtN.alt_config variable, and the isoc frame size for the current configuration is shown in the hw.ubtN.sco_rxsize and hw.ubtN.sco_txsize variables. By default, configuration 0 is selected, which means that no bandwidth is used on the Isochronous interface and no SCO data can be sent. Consult the Bluetooth USB specification at https://www.bluetooth.org/ for complete instructions on setting bandwidth consumption. The fol- lowing extract may be useful as a general guidance though details may differ between manufacturers. 0 No active voice channels 1 One voice channel with 8-bit encoding 2 Two voice channels with 8-bit encoding, or one voice channel with 16-bit encoding. 3 Three voice channels with 8-bit encoding 4 Two voice channels with 16-bit encoding 5 Three voice channels with 16-bit encoding SEE ALSO
bluetooth(4), uhub(4), sysctl(8) HISTORY
This ubt device driver was originally a character device written by David Sainty and Lennart Augustsson. It was rewritten to support socket based Bluetooth access for NetBSD 4.0 by Iain Hibbert. CAVEATS
Isochronous data is seemingly not well supported over USB in the current system and to get SCO working, you may have to calculate the SCO packet size that the stack will use. This is the sco_mtu value reported by the btconfig(8) command, and when combined with the SCO header (3 bytes) should fit exactly into an integer number of Isochronous data frames where the frame size is indicated by the 'hw.ubtN.sco_txsize' sysctl variable. For example: I want one voice channel (which is all that is supported, for now) so am using configuration #2, with a frame length of 17 bytes. This gives possible values of: (17 * 1) - 3 = 14 (17 * 2) - 3 = 31 (17 * 3) - 3 = 48 (17 * 4) - 3 = 65 (17 * 5) - 3 = 82 etc. btconfig(8) shows the maximum SCO payload as 64 bytes, so I am using the next smaller size of 48, to minimize the overhead of the 3 header bytes. The SCO packet size can be changed using the 'scomtu' option to btconfig(8). The failure mode is that the USB Bluetooth dongle locks up though generally removal/reinsertion will clear the problem. BUGS
The Isochronous configuration can only be changed when the device is not marked up. BSD
August 27, 2006 BSD