I don't think there is any significance to the 8/25 date. Thanks for the tip that the 25th is the day. I forgot.

[ Reply to This | # ]

ScamSource 2003 (ogg)

ScamSource 2003 (mp3)

[ Reply to This | # ]

http://creativecommons.org /licenses/by-sa/1.0/

[ Reply to This | # ]

I was actually loading a page from Caldera when everything went down.

[ Reply to This | # ]

[ Reply to This | # ]

Well, as of 21 Aug they were running Linux. I'm placing bets right now that in the morning it'll be runnin UnixWare, with Apache, no doubt.

[ Reply to This | # ]

PJ, isn't the rule(court, postal) 30 days to respond?

And, no response -- you lose?

[ Reply to This | # ]

http://stage.caldera.com/pro fservices/linux/

More here:

http://216.239.41.104/search?hl=en&lr=&ie=ISO-8859-1&q=site%3Astage .caldera.com+linux

[ Reply to This | # ]

It isn't possible to be perfect. I didn't see it either. I've posted the correction. The important thing is that you corrected as soon as you knew. Thanks.

[ Reply to This | # ]

But trying to connect why their server is not responding, stock is up and a 3 week old anonymous post on a blog is just unhealthy speculation. They could be out making crop circles or dancing naked in a mars is coming ritual but it wouldn't impact on the case until they issue a press release blaming linux and the GPL. You have provided the research and clarity missing from the mainstream press and Sco endlessly changing allegations. Please don't go weird on me!

Take care,

[ Reply to This | # ]

[ Reply to This | # ]

• Replacing Linux by UnixWare (getting the servers up again will take time and lotsa Jolt Cola)
• Combing through their websites to get any incrimination stuff off, like they do in '1984'. It is probably safer for them to be back with a minimum website come Monday

Actually, if their websites are down because any of the above they really suck. I always try to have no downtime when I do stuff like that of course I don't always succeed because I'm more or less the only Sysop in the company 8-/
This must then be a real panic attack manoeuver. I see the request from McBride. "CEO requests that all the websites be taken down NOW under penalty of firing"
Will the wayback machine have a deep copy of www.sco.com?

[ Reply to This | # ]

[ Reply to This | # ]

http://theinquirer.net/?article=111 80

basically states, "But there's no indication what the problems might be that are downing www.sco.com and www.caldera.com."

Will

[ Reply to This | # ]

John, I did my own traceroute here, and my results differ somewhat from yours (which is not that remarkable in itself, since we're probably not in the same neck of the woods). Tracing to www.caldera.com drops off the end of the world when it hits (129.250.16.52); however, tracing to www.sco.com makes it through that hop, but dies on the very next hop, at (198.173.159.254). Both of these are verio.net routers, and I did not see Verio listed as a Canopy company on Canopy's Web site.

By the way, I find it interesting that (a) all three companies (Canopy, Caldera, SCO) have their Web sites hosted in a Class C block held by NFT, the Noorda Family Trust (is it the same Noorda?), and (b) all three sites are hosted on Linux machines. In fact, www.sco.com was on a Unix machine until August of 2002, when they switched over.

[ Reply to This | # ]

bp

[ Reply to This | # ]

bp

[ Reply to This | # ]

[ Reply to This | # ]

http://newsf orge.com/newsforge/03/08/24/1228211.shtml?tid=17

[ Reply to This | # ]

http://www.nypost.com/business/39 34.htm

One other thing I don't think anybody has mentioned, unlikely to be related to the disappearance of their site, but worth considering I think

1. SCO uses their NDA presentation as a sales tool for their Linux license (speculation, but I think likely)

2. A Fortune 500 company sees the presentation and "gee it's the same code" (speculation), and buys a license (source: SCO press release)

3. Presentation is analyzed by Perens etc. (many sources)

4. Geeks or whoever shows the Fortune 500 CIO or whoever the Perens analysis or some other way he finds it (speculation)

5. If I was the Fortune 500 CIO, I'd be pretty annoyed (speculation)

6. McBride says the license is non-refundable (source: press reports). There are also some interesting clauses in the license about misrepresentation and breach of contract (source: LWN publishing text of license)

7. SCO is not going to give the money back to Fortune 500 (speculation from 6)

8. ???

[ Reply to This | # ]

"SCO/Caldera's site is being hit by a massive denial-of-service attack today. The timing, the scuttlebutt on Slashdot and elsewhere, and the contents of my mailbox all suggest strongly that the DOS attack was triggered by Darl McBride's slanderous interview[2] accusing the community of being IBM's sock puppets, and my response[3] to it."

...and...

"...I ask that the DOS attack cease immediately. Please stand down *now*. We have better ways to win this fight."

ESR is trying to hold the high ground, and I hope his message gets out. We certainly don't need to hand SCO any ammunition.

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

"I'm organizing a conference call early this coming week among a few key leaders to decide on the next stage of our response. Have patience. There is a plan developing, which I can't talk about because the element of surprise is part of it. We will counterattack at a time and place of our choosing and we will win." http://newsf orge.com/newsforge/03/08/24/1228211.shtml?tid=17

Can't wait to find out what's been cooking. :-)

SCO is gonna get plastered

[ Reply to This | # ]

I did a Whois search for Sco and Canopy and Center7 and some other Canopy holdings. Their DNS servers are not the same, except for Center7 and SCO share one in common. SCO's are: Name Server: NS.CALDERASYSTEMS.COM Name Server: NS2.CALDERASYSTEMS.COM Name Server: C7NS1.CENTER7.COM Name Server: NSCA.SCO.COM

Name Server: C7NS2.CENTER7.COM Name Server: C7NS1.CENTER7.COM Name Server: C7NS3.CENTER7.COM

Center7.com is still up and running.

I decided to try Visualroute myself, in case I was making mistakes, and for sco.com this is the report:

IP packets are not moving from network "Verio, Inc. VHIOI-198-1/0" to network "InterNAP Network Services, PNAP-DEN PNAP-DEN-INAP-BB-1" at hops 11-12.

XXX.XXX.140.1 sco.com NFT CENTER7-BLK

SCO is registered with Dotster. Dotster has this message on their home page:

"Attention:

"We are very sorry for the inconvenience. Your URL Forwarding experienced problems due to a filter being placed by our co-location hosting provider at about 5:00 am this morning that blocked URL Forwarding traffic. Unfortunately we were unaware of the downtime due to the fact that all forwarded sites were still fully operational on our end. There may still be some intermittent downtime from this morning but we are aware of the problem and our engineers are monitoring it closely. We have been in close contact with our co-location hosting provider and they are taking steps so an incident like this does not happen again. All sites should now be fully operational and if your site is not, it will be in the next 12 hours. Once again we apologize for the inconvenience and We thank you for your patience during this time."

[ Reply to This | # ]

Maybe dotster use URL forwarding in a different sense from other companys, But I thought URL forwarding generaly means they forward to a pre-existing web page (like a page on geocities or tripod) if you don't have name servers, proper hosting and all that stuff?

[ Reply to This | # ]

On Dotster message, it just indicates they are having some kind of a problem, and who knows yet what the whole story is. So, I'm waiting to draw any definite conclusion until I can reach someone there.

[ Reply to This | # ]

[ Reply to This | # ]

If you don't have it on your list already, could you do a profile of Judge Robinson, like the one you did on Judge Kimball?

[ Reply to This | # ]

11  den-core-01.tamerica.net (205.171.16.13)  53.092 ms  50.342 ms  52.572 ms
12  205.171.4.178 (205.171.4.178)  51.610 ms  51.596 ms  49.390 ms
13  fast-00-01.bdr01.den05.viawest.net (64.78.230.214)  64.924 ms  64.137 ms 
66.129 ms
14  gige-01-m00-00.crrt02.den05.viawest.net (64.78.230.210)  62.470 ms  62.158
ms  63.188 ms
15  pos-03-01.crrt01.slc03.viawest.net (64.78.227.10)  78.921 ms  78.905 ms 
79.679 ms
16  c7pub-216-250-136-74.center7.com (216.250.136.74)  78.953 ms  79.182 ms 
79.161 ms
17  c7pub-216-250-136-98.center7.com (216.250.136.98)  79.953 ms  77.927 ms 
79.443 ms
18  c7pub-216-250-136-254.center7.com (216.250.136.254)  76.252 ms  76.452 ms 
74.759 ms
19  fgw.calderasystems.com (216.250.128.253)  77.749 ms  75.717 ms  76.452 ms

piece of traceroute for sco.com:

11  den-core-01.tamerica.net (205.171.16.13)  50.123 ms  53.303 ms  52.058 ms
12  205.171.4.178 (205.171.4.178)  53.857 ms  51.864 ms  49.861 ms
13  * * *
14  * * *

DoS? Don't know, and have no evidence. Cease and Desist Order? Possible, at least one court in Germany has told them to shut up. Voluntary Site Shutdown? Possible, but they won't say anything meaningful.

20 mail.sco.com (216.250.130.37) 76.040 ms 76.211 ms 75.672 ms

[ Reply to This | # ]

El Tonno, because whether this turns out to be a DDOS or not, and I hope it doesn't, I am sending the message that I don't want even the perception that I approve of or ever would contribute to or condone such a thing, because I don't and I wouldn't.

[ Reply to This | # ]

$ /usr/sbin/traceroute www.sco.com ... 10 so-2-0-0.mp1.Denver1.Level3.net (64.159.0.241) 47.051 ms 47.184 ms 46.819 ms 11 gigabitethernet10-0.hsipaccess2.Denver1.Level3.net (64.159.3.122) 47.431 ms !H * 48.710 ms !H

$ /usr/sbin/traceroute mail.sco.com ... 10 so-2-0-0.mp1.Denver1.Level3.net (64.159.0.241) 47.025 ms 47.127 ms 46.913 ms 11 gigabitethernet10-0.hsipaccess2.Denver1.Level3.net (64.159.3.122) 46.700 ms 47.624 ms 47.365 ms 12 fbi.den.viawest.net (166.90.152.34) 47.874 ms 47.569 ms 47.357 ms 13 gige-01-m00-00.crrt01.den02.viawest.net (216.87.71.33) 53.513 ms 47.572 ms 47.448 ms ... and so on

The !H means 'no route to host', Ie, the router doesn't know how to get to the next hop, rather than the next hop simply not responding. www.sco.com and mail.sco.com are in different, but adjoining class-C subnets. Given how early the www.sco.com subnet 'breaks', it does NOT look like an near-client-router problem, but more an intervening router problem.

Either this is just a coincidence, or someone has done a router hack to destroy the routing for sco's first class-C. This is entirely possible through BGP pollution, but it requires someone with access to the main routing tables to insert false entries, or have very lax security. ie, someone's going to lose their job over this :)

On another note, my previous comment (different thread) about ir.sco.com being down is incorrect. It's working just fine, but is slow because it loads a lot of its graphics from www.sco.com. Another reason for avoiding 'leeching' from other sites :)

[ Reply to This | # ]

Yes the web server is, but sco.de **domain name** shouldn't be related to dotster at all right? I think it would be from http://www.denic.de/ - you should easily be able to check and confirm this.

And the name servers for sco.de don't come from SCO either?

I don't know the reasons for SCO's web problems either, just trying to research the background

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

I have not gotten !H or !N (host, network unreachable) messages
from my traces. I do get traces that look like this:

14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

[ Reply to This | # ]

traceroute to www.sco.com (216.250.140.112), 30 hops max, 38 byte packets
1 [censored]
2 [censored]
3 [censored]
4 se-6-1-0.tra-01.bru.net.tiscali.be (62.235.1.61) 5.623 ms 5.790 ms 5.646 ms
5 ge-9-12.sw-01.bru.net.tiscali.be (62.235.3.217) 5.166 ms 5.046 ms 5.185 ms
6 ge-3-1.gsr-01.bru.net.tiscali.be (62.235.3.210) 5.136 ms 5.103 ms 5.343 ms
7 pos-2-0.gsr-01.ant.net.tiscali.be (62.235.1.13) 6.080 ms 6.015 ms 6.052 ms
8 so-2-2-0.anr10.ip.tiscali.net (213.200.69.21) 6.350 ms 6.425 ms 6.323 ms
9 so-1-0-0.was21.ip.tiscali.net (213.200.81.154) 84.243 ms 84.370 ms 84.270 ms
10 interconnect-eng.Washington1.Level3.net (209.0.227.125) 84.614 ms 85.381 ms 84.355 ms
11 so-5-0-0.gar2.Washington1.Level3.net (209.244.11.13) 84.795 ms 84.959 ms 84.898 ms
12 so-3-0-0.mp1.Denver1.Level3.net (64.159.1.113) 157.141 ms 156.568 ms 156.778 ms
13 gigabitethernet10-0.hsipaccess2.Denver1.Level3.net (64.159.3.122) 179.753 ms !H * 179.759 ms !H


Stops somewhere in denver...nearby Utah at least. Guess I have to agree with Chris. And, Chris, thanks for the hint about the images at ir.sco.com. I should have thought about that myself.

[ Reply to This | # ]

 5  ae0-12.mpls2.Zurich1.Level3.net (213.242.66.18)  41.438 ms  136.012 ms
*
 6  so-0-0-0.mp1.London2.Level3.net (212.187.128.61)  110.537 ms  111.438 ms 
164.855 ms
 7  so-1-0-0.bbr1.Washington1.level3.net (212.187.128.138)  308.217 ms  261.392
ms  116.524 ms
 8  so-3-0-0.mp1.Denver1.Level3.net (64.159.1.113)  156.586 ms  216.394 ms 
144.993 ms
 9  gigabitethernet10-0.hsipaccess2.Denver1.Level3.net (64.159.3.122)  149.846
ms !H *  174.724 ms !H

So the router seems to have a problem because of the !H response. perhaps the sco-servers don't have to be down, they are only not "online".

[ Reply to This | # ]

man traceroute

[ Reply to This | # ]

Another good utility for traceroute/whois/nslookup is Sam Spade, which is available here if memory serves.

[ Reply to This | # ]

[ Reply to This | # ]

!H doesn't really mean 'host unreachable', but more like 'next hop unreachable'. It might help to explain a bit how traceroute works.

While 'ping' sends out a special 'ping' packet that the final destination is expected to respond to, traceroute instead sends out a 'UDP' packet with an unlikely port number (The 'why' is not necessary to know). Initially, it sends out the packet with a 'time to live' (TTL) value of '1', meaning that it will 'time out' (actually, 'distance out' is more accurate) after it gets to the first 'hop'. The 'hop' responds with an ICMP message saying 'time to live exceeded'. The bonus is sthat it also reports its IP address, which is why you can see the IP addresses of all the hops. traceroute typically does this three times, and then increases the TTL by one and repeats. This way, you can see most of the hops along the route.

The final destination wont respond with 'time to live exceeded' because, once it gets to where it's supposed to go, it doesn't care. Instead, it responds with 'port unreachable' because the UDP is going unanswered. 'traceroute' expects this, of course, and just reports the RTT (round trip times) as expected.

If something goes wrong, then different ICMP messages may - not always - be sent back. One of these is 'host unreachable', and if the traceroute program is flexible enough (not all are), then you'll see the !H message. There are a bunch of other messages, too, such as 'administrativly blocked' (!X) meaning it's been firewalled off. However, it IS possible to do all sorts of stuff at the router to change, or even just deny, messages being sent back. Ie, you might see values for hop 5, just stars for hop 6, and the values for hop 7. 'traceroute' uses sideeffects, rather than a proper protocol, to do its job. And, being sideeffects, it can be worked around.

Because the mail.sco.com traceroute goes a LOT further than the www.sco.com traceroute, this indicates that it's not the server, nor SCO's routers, that have been switched off. And, it's not likely to be a DDoS attack. This is either an accidental, or malicious, router misconfiguration or BGP (Border Gateway protocol - an automatic re-routing protocol) error.

[ Reply to This | # ]

!H doesn't really mean 'host unreachable', but more like 'next hop unreachable'. It might help to explain a bit how traceroute works.

While 'ping' sends out a special 'ping' packet that the final destination is expected to respond to, traceroute instead sends out a 'UDP' packet with an unlikely port number (The 'why' is not necessary to know). Initially, it sends out the packet with a 'time to live' (TTL) value of '1', meaning that it will 'time out' (actually, 'distance out' is more accurate) after it gets to the first 'hop'. The 'hop' responds with an ICMP message saying 'time to live exceeded'. The bonus is sthat it also reports its IP address, which is why you can see the IP addresses of all the hops. traceroute typically does this three times, and then increases the TTL by one and repeats. This way, you can see most of the hops along the route.

The final destination wont respond with 'time to live exceeded' because, once it gets to where it's supposed to go, it doesn't care. Instead, it responds with 'port unreachable' because the UDP is going unanswered. 'traceroute' expects this, of course, and just reports the RTT (round trip times) as expected.

If something goes wrong, then different ICMP messages may - not always - be sent back. One of these is 'host unreachable', and if the traceroute program is flexible enough (not all are), then you'll see the !H message. There are a bunch of other messages, too, such as 'administrativly blocked' (!X) meaning it's been firewalled off. However, it IS possible to do all sorts of stuff at the router to change, or even just deny, messages being sent back. Ie, you might see values for hop 5, just stars for hop 6, and the values for hop 7. 'traceroute' uses sideeffects, rather than a proper protocol, to do its job. And, being sideeffects, it can be worked around.

Because the mail.sco.com traceroute goes a LOT further than the www.sco.com traceroute, this indicates that it's not the server, nor SCO's routers, that have been switched off. And, it's not likely to be a DDoS attack. This is either an accidental, or malicious, router misconfiguration or BGP (Border Gateway protocol - an automatic re-routing protocol) error.

[ Reply to This | # ]

Odd. No?

[ Reply to This | # ]

Regarding www.sco.dom and www.sco.de. The sco.de site is in the same class-C as sco.com, meaning that it's not housed in Germany at all, but in the same location as the US site. And, since it's on the same class-C, it's having the same problems as sco.com.

So... not likely to be a DoS (or DDos), not likely SCO took the servers down themselves.

Unless, of course, SCO has told someone to screw up the routing to make it LOOK LIKE an attack, but that's just crazytalk! :)

D: It's possible that there's something filtering the ICMP messages that come back. I HAVE seen sites that only let certain ICMP messages through and if that's happening with you, then you'll see the effect you're seeing: rows of stars until hop 30, which is where traceroute gives up by default.

[ Reply to This | # ]

[ Reply to This | # ]

My traceroutes end:
13 sl-bb21-che-5-1.sprintlink.net (144.232.18.5) 317.875 ms 281.955 ms 267.459 ms
14 sl-gw10-che-10-0.sprintlink.net (144.232.15.166) 132.715 ms 133.131 ms 133.637 ms
15 sl-internap-100-0.sprintlink.net (160.81.54.46) 136.298 ms 136.473 ms 135.898 ms
16 * * *

didn't see any !H or the like. If there's a DOS it could run via Level3, as the last router there has trouble.

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

brenda, hehe you're right ;). that's human, the curiosity.

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

http://computerworld.co.nz/webhome.nsf/UNID/1FA54B055D7DAF54CC256D810009201B

One other that is bugging me, is apart from SCO's initial reactions (Sontag told me, We know what's our code, It's our word against his), I thought, and believe they said they would issue a response to Perens analysis, Thursday or Friday, and AFAIK that didn't seem to happen. Can somebody cofirm what precisely they said about preparing a response to Perens.

[ Reply to This | # ]

The story was by Mitch Wagner, internet week. I can only assume he was told by Stowell or the SCO PR team.

[ Reply to This | # ]

The gentleman who purportedly had the conversation, Larry Rosenman is, judging by his homepage, heavily Christian. Okay, so this fact in itself is no dipstick for truthfulness, but I'm predisposed to believe him if he says that's what they told him.

[ Reply to This | # ]

Belzecue: I got in touch with Rosenman, and I spoke with Viawest myself. They didn't confirm the report. That doesn't prove it isn't so, but they just laughed when I told them what I had read and basically indicated, without technically confirming or denying officially, that no one there would be in a position to have given out that kind of information. I contacted Rosenman, and he said he contacted the NOC last night, and he says that's what someone there told him. By today, perhaps there is a policy of saying nothing. He spoke to an engineer today at Viawest (he is one himself) who said what he was told last night was "probably true" but he had just started his shift. I don't know what to believe at this point, but for sure the Usenet report isn't solid ground to stand on. As Rosenman said in his email, the saga continues.

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

Although they have made some comments, it is my perception that these were comments made earlier in the week as a sort of immediate response. So I'm still waiting if they have something more to say?

A Larry Rosenman won a $50 gift certificate from SCO recently. Make of it what you will. To see load this page (will take a long time unless you do it in text mode due to images linked from sco.com)

http://www. google.com/search?q=cache:em3nWBuDMlEJ:www.caldera.com/partners/estreet/0308/sco forum.html+%22Larry+Rosenman%22+SCO&hl=en&ie=UTF-8

[ Reply to This | # ]

Although they have made some comments, it is my perception that these were comments made earlier in the week as a sort of immediate response. So I'm still waiting if they have something more to say?

A Larry Rosenman (not sure if same one) won a $50 gift certificate from SCO recently. Make of it what you will. To see load this page (will take a long time unless you do it in text mode due to images linked from sco.com)

http://www. google.com/search?q=cache:em3nWBuDMlEJ:www.caldera.com/partners/estreet/0308/sco forum.html+%22Larry+Rosenman%22+SCO&hl=en&ie=UTF-8

[ Reply to This | # ]

There is a situation called 'Short squeeze' whereby the stock goes up if too many people speculate on it going down. An explanation for the SCOX phenomenon??

[ Reply to This | # ]

Unless, of course, the upper-level ISP and the target of the attack are owned by the same people... :)

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

Good point, but could it have been repeated reboot/crash cycles instead?

OTOH, there already were DOS attacks againts SCO in May. Didn't know about these. I'm not a good investigative reporter.

• Net attack crushes SCO Web site
• Press release
• SCO wirft Linux-Fans DoS-Attacken vor

Predictably, SCO (actually, Blake Stowell) accused the Linux-community of committing these misdeeds.

[ Reply to This | # ]

[ Reply to This | # ]

Well, I guess we will know more on Monday. It's 00:14 here, I'm for bed.

[ Reply to This | # ]

I'm inclined to agree with your analysis, however to quote netctaft.com:

" At the moment, it is not known whether the SCO site has been successfully attacked, intentionally taken down, has lost connectivity or has simply broken."

[ Reply to This | # ]

[ Reply to This | # ]

If it was a DDOS attack, I'd expect other services to be unavailable, or slow (like the mail servers) but they're not.

In a DDOS attack, you'd expect nearby servers in the block to also be slow, due to extensive broacasts and forwarding. That's not taking place. So, IMHO, SCO has shutdown their apache server to rebuild it, as they have been using Apache 1.3.14 and that version is vulnerable to a couple of attacks, so an upgrade would do them good.

[ Reply to This | # ]

I'd expect them to be complaining if it was an attack. I haven't seen a complaint, so this makes me wonder.

And while there were some news reports on Thursday/Friday, I haven't seen any *new* reports with SCO contributions after about Thursday.

None of this proves anything, just makes me wonder.

[ Reply to This | # ]

http://www.i tnews.com.au/storycontent.cfm?ID=17&Art_ID=12755

ht tp://www.zdnet.com.au/newstech/os/story/0,2000048630,20277673,00.htm

Update: http://www.zdnet.com.au/newstech/enterprise/story/0,2000048640,20277500,00 .htm

[ Reply to This | # ]

[ Reply to This | # ]

- PJ especially

http:/ /www.aberdeen.com/ab_company/hottopics/linuxvunix/weblog.htm

Some pretty strong words, like

"destroy Linux business" "blackmailing" "without a shred of evidence" "extort license fees via non-substantiated charges" "blackmail"

[ Reply to This | # ]

[ Reply to This | # ]

Their shredders are probably working overtime this weekend - including multiple instances of BCWipe.

[ Reply to This | # ]

Looking at some of the netcraft graphs it seems very reasonable that SCO was under some kind of usage that prevented queries, or sent the query times very high, and then nothing at all. That fits in well with the explaination that they were DoS'd or DDoS'd and then a block put in place at viawest. I wish I was checking before that block was in place, traceroutes then would have been much more telling.

[ Reply to This | # ]

I re-read one log of the July 21 conference call (I didn't listen so just going by the log). Check for yourself

Laura DiDio, yes that DiDio, about question 10, asked McBride whether he could be sure the code was not BSD or some Linux version?

McBride replied it's not BSD. And he's talking about Linux 2.4 and high-end SMP

So if the SCO position is now, yes it's BSD, but it's ours (which it might or might not be depending on how you read their statements), this is a reversal in a position, at best.

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

Given that SCOG was shaking down some of the AT&T lisencees IBM, SUN and Microsoft in late 2002 and IBM called them on their bluff. SGOG had to do something, so they came up with the convinient fiction that big blue had some how given the linux hippies (those commie pinko rats) the keys to the store.

Read about the Trillian Project, The HA Linux Project, and The Linux Scaliblity Project to find some of the original sponsors.

All before Itty Bitty Machines started pushing the "Linux Solution" and supporting the project...

[ Reply to This | # ]

1. it's the Old SCO (although I guess there might some people at the New SCO who rememer being involved) that was in Monterey.

2. According to Claybrook, IBM was the only company who was interested. Sounds to me more like IBM rescuing SCO, after everybody else was happy to let them drown.

3. They didn't seem too unhappy at the time

4. The law suit is against IBM. Despite SCO now saying the code is general evidence against Linux, CNET says they were presenting it otherwise just days ago.

5. If there is evidence of wrong-doing in this code, it doesn't seem to implicate IBM.

[ Reply to This | # ]

7. BPF definitely, and by the looks of it the malloc stuff, are found in BSD. According to the transcript of July 21st that I just read, McBride told DiDio that the examples were not BSD.

[ Reply to This | # ]

Caldera/SCO was never involved in Project Monterey. That was the old Santa Cruz Operation. IBM announced that it was pulling out of Monterey, and transferring the technologies to linux, a full nine months before Caldera purchased the UNIX properties from Santa Cruz Operation. That's what makes so many of Caldera/SCO's lawsuit claims ludicrous. Caldera purchased these properties months after the Monterey cancellation was public knowledge. At the same announcement, IBM stated that the technologies that had been contributed by IBM to Monterey would now be going into linux. Caldera knew this. They were IBM's supplier of linux at the time.

All these claims from Caldera about how they were tricked or surprised by IBM's decision to move certain technologies into linux are so much rubbish. Their claims that this behavior "devalued" the UNIX properties is also ludicrous; Caldera knew of the Monterey cancellation AND the move toward linux months before they closed the deal to buy the UNIX properties. If they did not correctly factor that knowledge into the price they were willing to pay, then that is their problem. It sounds to me like the Santa Cruz Operation got the best of them in a price negotiation, and sold them a bag of 20- and 30-year-old for a lot more than it was worth. That's not IBM's fault, and there's no reason IBM should pay Caldera for their own mistake.

[ Reply to This | # ]

IBM has shown themselves to be tepid to lukewarm at best over the prospects
of the IA64 chip family. SCOG, views these chips, slow -- very slow selling chips<br< as their salvation. Big Blue, didn't and doesn't.

[ Reply to This | # ]

So what? I wasn't aware of IBM being under a contractual obligation to enthuse about IA64 chips?

[ Reply to This | # ]

My point? Good question, to put it simply, I view Blues participation
in P. Monterey as a vapor product. Their actions seem to show that I
might be correct. The ironic part is that HP, SGI and the rest of the
Trillian partners, beat BB to the punch. And SCOG is too stupid to
realize this.

q, you are very good at getting links to relevant information. And I do
apreciate your work. Try finding the following, "vaporware", FUD, and
"You can't get fired for buying ..." And you will find out who these terms
originally were coined for.

[ Reply to This | # ]

http:// asia.cnet.com/newstech/industry/0,39001143,39148108,00.htm

[ Reply to This | # ]

If P. Monterey was vapor, it's at least arguable why it stayed that way.

If one of the SCO's suffered, it was old SCO, not new SCO.

In any case, Old SCO was involved, not new SCO. New SCO must have known, or at the very least should have known, Monterey was dead in the water, before they got involved with their UNIX acquisition.

If Monterey is the cause, why wait so long?

If Monterey is the cause, why is new SCO suing, not old SCO?

And I'm still unaware of IBM being under any obligation to enthuse about IA64, let along exclusively enthuse about IA64.

And maybe I'm dense, but I stll don't see the relevance of your "tepid to lukewarm" comment, to any of my previous posts. So I can't figure out why you addressed it to me.

[ Reply to This | # ]

[ Reply to This | # ]

quartermass and Bob: there seems to be some confusion over what Caldera bought. Old-SCO split itself into a number of subsidiaries, and it was the Unix-related business units (not just licenses) that Caldera bought. That makes Scaldera, rather than Tarantella, the continuation of the business that participated in Monterey. That's why new-SCO brought it into their lawsuit: "On or about May 2001, IBM notified plaintiff that it refused to proceed with Project Monterey, and that IBM considered Project Monterey to be 'dead.' In fact, in violation of its obligations to SCO, IBM chose to use and appropriate for its own business the proprietary information obtained from SCO." So, even if they can't ultimately trace it to IBM, the IA64 port is going to be one of the places they will have concentrated on to find simliarities with Linux.

It's certainly true that new-SCO's findings aren't doing a very good job of supporting the claims, but it's easy to see why that portion of the source tree would be interesting to the company, and why any simliarities found there would lead them to jump so quickly to allegations of plagiarism. (monterey wasn't just an IBM-SCO thing. Pre-IBM Sequent, Compaq, Samsung, Unisys, Bull, Acer and ICL were also on board.)

[ Reply to This | # ]

But

> That makes Scaldera, rather than Tarantella, the continuation of the business that participated in Monterey

is open to dispute. IBM will (already have in their filing), argued that.

Ignoring the legal side, and thinking about purely the *justice* side. If the business units were damaged (by IBM or anybody else or any other cause), prior to new SCO's purchase... and new SCO took that into account in the purchase price, it's hard to argue, they suffered.

Let's say I buy a wrecked car from the scrap yard for $50. Am I going to get any joy suing the people who wrecked it and arguing that if they hadn't, I'd have got a mint condition classic Ferrari for $50? What about if I use the $50 scrap metal in my business for 2 years, then turn round and say, I'm not making money, now I realize I should have had that mint Ferrari for $50.

IA64:

- All the pre-IBM and non-IBM stuff, except possibly for IBM subsiduaries, is NOT relevant to the SCO case which is AGAINST IBM!

- It also doesn't change the fact that SCO presented this as "proof" against IBM (read that CNET article). If anybody is implicated, it's SGI, and possibly HP.

- It also doesn't change the fact that SCO represented their "proof" as not being BSD.

- Both the above two items, could be relevant to IBM's counter claims.

If I say Ian is a member of this Club, and commits this type of crime, here's the proof... but later, when it's revealed that the "proof" is not related to Ian at all... so I say well actually it's not about Ian, it's just some other member of the Club.... I would still have libelled Ian... at least in the moral sense, and quite possibly in the legal sense too.

[ Reply to This | # ]

Ignoring the legal side, and thinking about purely the *justice* side. If the business units were damaged (by IBM or anybody else or any other cause), prior to new SCO's purchase... and new SCO took that into account in the purchase price, it's hard to argue, they suffered.

The timing is very interesting there, actually. Scaldera claims that IBM closed down the alliance in May 2001, the same month the transfer from old-SCO to Caldera was made final. (The buyout was first announced in August 2000) Given that version of the timeline, Caldera wouldn't have been able to figure the ended collaboration into its purchase price.

Caldera apparently screwed up big time on the due diligence, and didn't make sure that there was any guarantee of deliverables attached to that project. With an aging legacy product line that was seeing a trend of decreasing revenues over the past few years, and the cancellation of the hoped-for replacement, they had to find a way to squeeze a return out of the purchase. Hence, SCOsource.

SCOsource never had IBM as its only target. It was set up as "a division of SCO that will expand the licensing of the company's core intellectual property, including the core UNIX source code." That's why contributions from SGI (or according to some accounts, mislabeled HP contributions) are being put on display. (The packet filter example looks like plain old confusion on Scaldera's part, it really looks as though Scaldera may not be privy to all the details of the BSD/USL settlement.) IBM just happens to be their biggest fish at the moment. It's doubtful they have the resources to actually go through with filing suits against more companies simultaneously, so they're hoping to leverage the publicity from the IBM suit into bringing other potential sources of license revenue into submission.

Sure it's a stupid business plan, but having seriously screwed themselves with a stupid purchase, there really wasn't a lot left for Caldera to do, besides sitting around quietly in the corner and going out of business.

[ Reply to This | # ]

Public announcement of Monterey cancellation on August 28, 2000, nine months before purchase of UNIXware by Caldera.

[ Reply to This | # ]

This is from SCO's amended complaint:

58. By about May 2001, all technical aspects of Project Monterey had been substantially completed. The only remaining tasks of Project Monterey involved marketing and branding tasks to be performed substantially by IBM.

59. On or about May 2001, IBM notified plaintiff that it refused to proceed with Project Monterey, and that IBM considered Project Monterey to be “dead.”

Bob's link noted

[ Reply to This | # ]

This is from SCO's amended complaint:

58. By about May 2001, all technical aspects of Project Monterey had been substantially completed. The only remaining tasks of Project Monterey involved marketing and branding tasks to be performed substantially by IBM.

59. On or about May 2001, IBM notified plaintiff that it refused to proceed with Project Monterey, and that IBM considered Project Monterey to be “dead.”

Bob's link noted

[ Reply to This | # ]

"We won't make Unix proprietary," said [Caldera CEO, Ransom] Love. "The future is an open internet platform."

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

On Project Monterey, as it happens, I'm working on an article about it. Sneak peak at bottom line: they didn't want to go forward with it either at the time. As usual, history has been rewritten. There were market forces that convinced everybody to stop, from all that I can see. If anyone has any other links (thanks Bob) by all means contribute. I should have it done in about a week.

Thanks to everyone for figuring out what is going on with the site being down, or a reasonable facsimile. If accusations are made, I'll be surprised. Also ready.

[ Reply to This | # ]

Another interesting thing - SCO became interested in reviving Monterey in August 2002

http://www.informat ionweek.com/story/IWK20020830S0023

"We've got a lot of technology done from Project Monterey."

"It would be a large investment," Broughton admits.

To me at least, it certainly doesn't sound like all the technical aspects were completed according to item 58 in their amended complaint.

[ Reply to This | # ]

Press seems to have upgraded Perens analysis from "Linux advocates" to "experts"

http: //www.cmpnetasia.com/ViewArt.cfm?Artid=21004&Catid=8&subcat=79

[ Reply to This | # ]

[ Reply to This | # ]

http://www.google.com/search?q= cache:zbqiT5dR9jYJ:techupdate.zdnet.com/sp/stories/news/0,4538,2617766,00.html+C aldera/SCO's+take+can+be+summed+up+&hl=en&ie=UTF-8

"Caldera/SCO's take can be summed up as it can see why it is time to wind up Monterey. After all, with the advances of Project Trillian, 64-bit Linux for Intel, there's little practical point to spending more time and effort on advancing another 64-bit Unix. IBM's timing and presentation, however, are another matter."

http://linuxtoday .com/infrastructure/archives/200008/21

[ Reply to This | # ]

This being said, if IBM really took SCO for a ride, why isn't SCO suing IBM over AIX rather than Linux, and why did they wait so long?

Hmmmm...

[ Reply to This | # ]

[ Reply to This | # ]

Look at pages:

http://www.f-sec ure.com/news/items/news_2003082300.shtml

http://www.f-secure.com/v-d escs/sobig_f.shtml

It was supposed to download its second stage payload from one of 20 servers around the world at Aug 22 19:00 UTC.

Afterwards the second stage is supposed to activate.

F-secure claims that 19 of 20 machines were taken downline before 19:00UTC, one machine was up and remained tons of requests. The 20th machine got swamped under the requests.

There is also a mention that it will also activate on 24th August.

That provides two possibilities: 1. One of the machines was in the mentioned subnet. 2. One of the machines was one of the mentioned servers and hence the DDos.

The mention on Aug 24 may be the reason why it is still down.

[ Reply to This | # ]

http://www.theregister.c om/content/35/32479.html

[ Reply to This | # ]

Is anyone checking the money trail with the other Canopy Group companies?

[ Reply to This | # ]