] MOST electric vehicles work by connecting the wheels to a
] motor. But tomorrow a Dutch company plans to unveil a bus
] in which motor and wheel are one, a refinement that
] promises more miles per charge and a vehicle that is
] safer and easier to maintain.

Cool!

With a Motorized Hub, the Wheel on the Bus Goes 'Round

] 2. Verisign has been sniffing glue.

Clearly!

RE: Verisign back in the fraud?!

] SCO's references to XFS are completely misplaced. XFS is
] an innovative SGI- created work. It is not a derivative
] work of System V in any sense, and SGI has full rights to
] license it to whomever we choose and to contribute it to
] open source. It may be that SCO is taking the position
] that merely because XFS is also distributed along with
] IRIX it is somehow subject to the System V license. But
] if so, this is an absurd position, with no basis either
] in the license or in common sense. In fact, our UNIX
] license clearly provides that SGI retains ownership and
] all rights as to all code that was not part of AT&Ts UNIX
] System V.

SGI's open letter r.e. SCO

] The SCO Group is extending its royalty campaign to
] encompass Silicon Graphics Inc. The company says it will
] revoke SGI's Irix license on October 14. It's no
] surprise, as SCO CEO Darl McBride has explicitly
] mentioned SGI over a month ago. SGI signed the license
] with AT&T in 1986.

The Register

] Residential fuel cells sound almost too good to be true.
] Take a hydrocarbon fuel such as natural gas, use a
] catalyst to extract hydrogen from it, react the hydrogen
] with air and, presto, you have a home power plant!

Excellent idea!

ScienceDaily News Release: Rating The Performance Of Residential Fuel Cells

Also of note: IBM will not indemnify Linux customers:

] In the memo, signed by Robert Samson, an IBM sales
] manager, IBM said that: " Most indemnities are narrowly
] drawn and are often invalidated by customer activities,
] such as making modifications or combining the indemnified
] product with other code, which are central to the
] vitality of open source."
]
] It said the H-P indemnification requirements "will
] inhibit customers from taking full advantage of the open
] source development process."
]
] Mr. Samson's memo says "HP's approach as outlined in the
] press, we believe runs fundamentally counter to the Linux
] value proposition." Many users like Linux because they
] can view the source code making it easy to adapt the
] operating system for their own uses.

IBM Files New Claims Against SCO in Linux Case

Good interview. I keep forgetting about project Monterey ... and how that may have really been the start of this whole mess.

Ransom Love, Co-founder of Caldera and SCO, Speaks of Unix, GPL and the Lawsuit

]
] When SCO CEO Darl McBride wrote his open letter last
] week, he seemed to indicate a hope there could be a
] viable future partnership between his company and Linux.
] There is more than a hint as to what that partnership
] might be like in two research papers prepared back in
] March and April by Renaissance Ventures, a VC firm that
] invested in SCO.

(lots of other good SCO stuff on groklaw today)

This gives some good insight as to what's going on with SCO's stock price and just exactly what crack the investors are smoking. With the new IBM suit filed today, they've dropped another $2.30 (as of midday) to $14.92.

Like I've said before: IBM won't settle -- they can drag out the litigation indefinitely until SCO is bankrupt. Remember that the US tried to sue IBM once ... and threw in the towel after 8 years! SCO's strategy was to bluff IBM into settling before trial -- and IBM called it.

GrokLaw: Visions of Ka-ching Dance in Their Heads

] Particularly controversial was the claim that SCO had the
] capability to launch a wave of invoices within 45 minutes of an
] outbreak of licence infringement.

] This was flatly contradicted by intelligence reports, which
] insisted that the only weapons in the company's armoury were a few
] elderly FUD missiles and the odd bluster bomb.

LOL!

SCO's FUD missiles rain down on the infidel

Decius wrote:
] ] We call on ICANN to examine the procedures for changes in
] ] service, including provisions to protect users from
] ] abrupt changes in service.
] ]
] ] We call on the IAB, the IETF, and the operational
] ] community to examine the specifications for the domain
] ] name system and consider whether additional
] ] specifications could improve the stability of the overall
] ] system. Most urgently, we ask for definitive
] ] recommendations regarding the use and operation of
] ] wildcard DNS names in TLDs and the root domain, so that
] ] actions and expectations can become universal.

] If this issue is not resolved by Phreaknic I will use my
] speaking time there to call for a move to a DNS system that
] exists outside of ICANN's control. Its not really their fault,
] but this situation cannot be allowed to go on for years.

There's always opennic (www.opennic.unrated.net or www.opennic.glue if you already have it set up). This doesn't help with the *.com problem, though. The CMU Computer Club's nameservers are set up that way -- 128.2.4.142 and 128.2.4.151 -- feel free to play with it but be advised that those addresses may change in a few months.

One thing that I advocate doing with recursive nameservers regardless of your position on ICANN, etc, is rather than having a root.cache that just lists root nameservers, sync the root zone and have the hints point to all of the nameservers for all of the TLDs. This reduces latency since you never go to root servers -- good queries go straight to the NS for that TLD and your server can immediately generate an NXDOMAIN for queries that don't correspond to any TLD.

RE: ICANN can't do anything...