Litigation Utah-Style - the Hatch-Jenson (Robbins) Connection - Updated

 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements UNIX and Linux RSS News Litigation Utah-Style - the Hatch-Jenson (Robbins) Connection - Updated
# 1  
Old 12-08-2009
Litigation Utah-Style - the Hatch-Jenson (Robbins) Connection - Updated

If you are finding the Pelican litigation impenetrable, all I can say is, so am I.
But in my efforts to figure it out, I came across an interesting detail. It seems Brent Hatch's law firm, which represents SCO, also represents Marc Sessions Jenson, a business partner in at least one deal with Mark Robbins, the plaintiff in Pelican. Jenson and Robbins are co-defendants in a litigation currently before Judge Ted Stewart, the judge now assigned to SCO v. Novell, a case titled Hansen, et al v. Bk One UT NA, et al. I know. Utah is a small world indeed.
Might that Hatch-Jenson connection to Mark Robbins be at least part of why Darl McBride was let go, I can't help but ask? How could Hatch represent SCO, with McBride at the helm, and also represent Jenson, whose business associate, Mark Robbins, is suing McBride in New York State in the Pelican mess? I don't know if they are still associates, but it's awkward, no?
Wait. There's more.

More...
Login or Register to Ask a Question

Previous Thread | Next Thread

2 More Discussions You Might Find Interesting

1. Solaris

Solaris 10 ftp connection problem (connection refused, connection timed out)

Hi everyone, I am hoping anyone of you could help me in this weird problem we have in 1 of our Solaris 10 servers. Lately, we have been having some ftp problems in this server. Though it can ping any server within the network, it seems that it can only ftp to a select few. For most servers, the... (4 Replies)
Discussion started by: labdakos
4 Replies

2. News, Links, Events and Announcements

Microsoft and Sun Settle Litigation

http://www.microsoft.com/presspass/press/2004/apr04/04-02SunAgreementPR.asp no comments sad pressy (1 Reply)
Discussion started by: pressy
1 Replies
Login or Register to Ask a Question
ISDNTEL(4)						   BSD Kernel Interfaces Manual 						ISDNTEL(4)

NAME
isdntel -- ISDN B-channel telephony interface driver SYNOPSIS
pseudo-device isdntel count DESCRIPTION
The isdntel driver provides an interface to the B-channel for telephony applications and is currently used by the isdnd(8) for answering machine support. The driver is part of the isdn4bsd package. The lower six bits of the driver's minor number are used to specify a unit number, whereas the upper two bits specify a functionality. Functionality zero is the usual telephony data stream i/o driver. Functionality one is used to enable commands to dial out and hang up and receive responses about the state of the dial out progress and sta- tus. This commands may change in the future, for details see the file /usr/include/netisdn/i4b_tel_ioctl.h and the isdntel(8) utility. The telephony data stream comes out of the line in a bit-reversed format, so the isdntel driver does the bit-reversion process in any case. Additionally, the user can specify to do A-law to mu-law, mu-law to A-law or no conversion at all in the isdntel driver by using the isdntelctl(8) utility. The driver is able to process several ioctl's: I4B_TEL_GETAUDIOFMT get currently used audio format conversion. I4B_TEL_SETAUDIOFMT set currently used audio format conversion. I4B_TEL_EMPTYINPUTQUEUE clear the input queue. For the I4B_TEL_GETAUDIOFMT and I4B_TEL_SETAUDIOFMT, the following parameters are available: CVT_NONE do no A-law/mu-law audio format conversion. The conversion path looks like this: USER <--> bitreversing <--> ISDN-line CVT_ALAW2ULAW set audio format conversion to do an audio conversion from A-law (on the ISDN line) to mu-law (in the userland). The read(2) conversion path looks like this: USER <-- mu-law/A-law <-- bitreversing <-- ISDN-line and the write(2) conversion path looks like this: USER --> mu-law/A-law --> bitreversing --> ISDN-line CVT_ULAW2ALAW set audio format conversion to do an audio conversion from mu-law (on the ISDN line) to A-law (in the userland). The read(2) conversion path looks like this: USER <-- A-law/mu-law <-- bitreversing <-- ISDN-line and the write(2) conversion path looks like this: USER --> A-law/mu-law --> bitreversing --> ISDN-line SEE ALSO
isdnd.rc(5), isdnd(8), isdntel(8), isdntelctl(8) STANDARDS
A-law and mu-law are specified in ITU Recommendation G.711. AUTHORS
The isdntel device driver and this man page were written by Hellmuth Michaelis <hm@kts.org>. BSD
April 21, 1999 BSD