Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
The Pulpit

<< [ Technician, Steal Thyself ]   |  Twice As Much Nothing to Watch on TV  |   [ What Goes Around Comes Around ] >>

Weekly Column

Twice As Much Nothing to Watch on TV: How Ultra Wide Band Networking May Change Cable TV; Also, How SCO Unix May, Itself, Have Code Ripped-Off From Both Linux and BSD Unix

Status: [CLOSED]
By Robert X. Cringely

For those technical diehards who are still interested in the ongoing saga of SCO versus Linux and most of the rest of the world, that story continues in the second half of this column. But for those who rightly think that there must be other things happening in the world of high tech, let's begin with something very different -- a new way of looking at Ultra Wide Band (UWB) networking.

I first wrote about UWB in January of last year, back before most folks had ever heard of it. The idea was compelling -- a new kind of wireless data networking that promised almost unlimited, totally secure bandwidth over long distances without interfering with other radio communication. UWB did this by sending carefully-timed pulses across the entire RF spectrum. To other radios, it would sound like noise, but that noise would be sending gigabits-per-second even to receivers underground. Wow!

Well, it didn't turn out that way. Shortly after that column appeared, the FCC approved UWB, but did so at severely reduced power levels. The result was that what had been pitched as a Wide Area Network (WAN) technology was now limited to being more of a Personal Area Network (PAN) technology with a maximum effective range of about 10 meters. With gigabit speeds, it isn't enough to say that UWB is Bluetooth on steroids. UWB is thermonuclear Bluetooth.

The FCC regulations sent a tremor through the nascent UWB industry as all the companies that were developing products tried to find ways to make money sending massive amounts of data only 30 feet. It didn't look good, except at a UWB company in San Diego called Pulse-Link -- a company nobody has ever heard of.

I am not a shill for Pulse-Link. I have no relationship with the company, own no stock, and have no personal interest at all in their success. I just happen to find what they are doing to be very interesting.

Faced with this bad news, Pulse-Link did something the others hadn't: they considered applying the same technology to wired networks that they were using for wireless. UWB is, after all, a form of communication using radio frequency energy, and RF travels even better over a wire than it does through the air, thank you.

The advantage to using wired UWB was two-fold. First, it completely got around the FCC power limitations of wireless UWB. And second, none of the other UWB companies seemed to be even considering it. Then a patent search showed that for some weird reason, nobody had apparently EVER thought of running UWB over a wire. The upshot of this is that Pulse-Link has now filed patents with more than 400 claims completely defining wired UWB. When this market matures, they will own it.

The primary market that interests them is cable TV. Through bootleg experiments in the Chief Technical Officer's apartment building, Pulse-Link discovered that they could send their signal on the same cable as a digital cable TV signal without bothering the TV signal at all. Even better, they discovered that the crude way the CATV industry does data conversion for fiber also converts the UWB signal, which looks like noise.

Let me explain that part again. While the TV cable behind your house is coaxial and carries an electrical signal, it is very common for cable TV systems to use fiberoptic cables to send the signal over longer distances from the cable head end to your neighborhood. This requires the digital cable signal to be converted from an electrical signal to an optical signal and back again. We do the same thing with computer data networks except those involve a protocol conversion where electrical data is recognized as data, converted to optical data, then reconverted to electrical data. This kind of conversion has always been seen as an advantage of digital data networks since the signal is constantly being regenerated and is not subject to fading or corruption. But things are done differently in the cable TV world, where what is converted isn't data, but just a wave form. Rather than filtering out noise, for example, it is just converted from electrical to optical to electrical right along with that episode of “The Osbournes.”

The result is that a single UWB signal can go from one end of the cable TV network to another just as long as it is running on copper at the beginning and the end.

To see why this makes a difference, look at another networking company, Current Technologies, which is getting ready to bring us the Internet over medium voltage electric power lines like the one running past your house. Current is limited to a power line backbone of less than a mile, which means it has to have a second network to get the data to your neighborhood, where it can then be accessed over the power line after the data is converted and injected onto the electrical line. The bandwidth of current is limited to tens of megabits-per-second on the neighborhood backbone and less than two megabits-per-second to your house. Pulse-Link's bandwidth, on the other hand, is 1.2 gigabits-per-second downstream and 480 megabits-per-second upstream end-to-end. That's a LOT of bandwidth.

This is obviously not just enough bandwidth for Internet and phone service but also for TV. Pulse-Link's plan is to work with cable TV companies to sell this service, which is to be installed without a truck roll (every installer truck roll costs $250 in labor, capital, and logistical support, which means the cable TV company doesn't make a profit until the second year of service). The customer just unplugs their present cable box and plugs in the new UWB box right where the old one was. Current still has the advantage that HomePlug technology takes its signal to every electrical outlet in the house, but Pulse-Link has the advantage that the cable company can use much of that bandwidth for video-on-demand, which means real revenue and yet another headache for Blockbuster.

We'll just have to come back to this subject in 2005 and see what happened.

Now back to SCO, which this week is offering to show journalists, including me, the Unix System V code the company claims IBM installed in Linux. Seeing this demonstration, however, requires signing a nondisclosure agreement, so I won't do it. Someone else will, I'm sure, and we'll all hear about it soon.

In the meantime, another furor has erupted concerning SCO Unix's ability to run Linux binaries. Other people have written about this, and I have talked to some of their sources, and it comes down to the idea that SCO didn't reverse-engineer Unix to run those binaries; they claim to have copied code directly from Linux to Unix. To those who think this isn't a problem, take a look at the Linux General Public License and you'll see it very much is a problem since SCO doesn't release Unix source code to regular customers and the GPL requires open source.

So at the same time SCO is blaming IBM for putting Unix System V code into Linux, Linus Torvalds (as the Linux copyright holder) may have a claim against SCO for putting Linux source code into SCO Unix.

But wait, there's more! Going back to the original problem of finding common code in Linux and Unix � there’s that side-by-side demonstration SCO is offering to do this week. If IBM didn't put it there, who did? An emerging theory suggests that both Linux and SCO Unix have code taken from BSD Unix, which would explain how they could be identical without one having stolen it from the other. Both code samples may have a common antecedent.

At this point, I need to say that what follows is not my idea, but a logical train of thought that was presented to me. I'll take someone else's good ideas anytime.

Don't tell SCO this, but if you are trying to figure out how to do Unix reasonably well, almost the last place you want to look is the System V code. Most Unix vendors had to spend several years fixing it before it was production strength.

There is at least one other possible source for Unix source code, one with an excellent reputation for quality and performance -- BSD Unix, so-called Berkeley Unix. You might remember that back in 1992, AT&T's Unix Systems Laboratories (USL) sued UC Berkeley for giving away Unix source code. Once they got to court, USL (which was by then owned by Novell, not AT&T) ended up setting very quietly, paying UC Berkeley's legal expenses in the process. Not many people seem to know why that happened.

One of SVR4's biggest features was that it combined traditional System V with a lot of popular BSD features. To do this some significant amounts of BSD code were pulled into System V. This would not normally be a problem because the BSD license allows it if the code is properly attributed. I have been told, however, that AT&T removed UC Berkeley copyrights and replaced them with AT&T copyrights. This reportedly came out during the lawsuit. So rather than Berkeley having stolen AT&T code, it was the other way around!

Unlike System V, the BSD source code is very widely available and has been since the NET2 release that triggered the AT&T lawsuit -- long enough ago to have possibly been influential to Linux developers.

Did the Linux kernel developers look at BSD? At least some of them did. In fact, people who are far smarter than I am about these things report there was at least one case where BSD developers noticed that significant amounts of Linux kernel code was stolen verbatim from BSD with attributions removed and GPL copyrights added.

So it is probable that both System V and Linux developers ripped off BSD code. Since some BSD copyrights were obliterated by AT&T, SCO would not necessarily notice that code in question was really from BSD. And since there are probably few, if any, SCO developers who were involved with the creation of System V back when it was AT&T property they would have no institutional memory of this. It would appear to them that Linux developers stole their code, and not apparent that their code was itself stolen.

If true, this taints both Linux and Unix, which is sad, but hey, life goes on. It should be very interesting to see how it all plays out. What I STILL can't figure how SCO blames this all on IBM.

Comments from the Tribe

Status: [CLOSED] read all comments (0)