If you could compress the standard 30-second adverts by a factor of 10, you get the three-second BlipVerts "invented" by George Stone, Rocky Morton, and Annabel Jnakel. Remember the original idea: "BlipVerts happen so fast, they're over and embedded in viewers' minds before they have a chance to channel-switch."
The updated patent filing would read, "BlipVerts happen so fast, they're over and embedded in viewers' minds before they have a chance to fast-forward past them."
Couple that with the research that has been done on driver reaction-time and you can see that editing out commercials on-the-fly would be virtually impossible; indeed, you would need the electronic equivalent of an A/B Roll Editor to get rid of the pesky things. For those shows with a high beer-drinking quotient (like football games, guy), the BlipVerts could extend to six seconds because the alcohol-sotted viewer would need several seconds to find the button, let alone press it enough to make contact. So says the driver-reaction studies over the past 30 or so years.
The movie Max Headroom: 20 Minutes Into the Future (later released to video as Max Headroom, The Original Story) postulated a solution that assumed real-time viewing. Interesting that the same solution would apply to the easy time-shifting that the TiVo and ReplayTV enable.
(To show just how prescient the writers of the original script were, just how soon do you think it will happen that a television network executive will be able to propose this solution to a knotty scheduling war: "We can go porno early.")
I sympathize with your plight. Having gone through a similar issue with Pacific Bell Internet earlier in the year, I know how frustrating it can be. In short, the service sucked.
My problems were not on cable modem service, but DSL. I was able to locate and strike a deal with a local ISP that was a "DSL partner" to switch the ISP provisioning from PBI to the local ISP.
It is experiences like yours that keeps me working toward ISP equal access on cable. When the ISPs don't have a captive market, they tend to pay attention to maintenance. A monopoly, especially one that doesn't have to answer to anyone except possibly a class-action lawsuit, tends toward cavilier toward the finer stuff.
Case in point: the only reason FTP access would be down more than a couple of days is because no one is working on it. I've had FTP servers go down on me, and I was able to bring them back up in hours, not days and not especially a month.
As long as the FCC allows monopoly ISP service for cable modems, we will continue to see complaints like yours.
There was once a movement by the ad industry to pressure TV manufacturers to have the "mute" button not completely kill the audio, but instead to reduce the volume by around 45 dB. I have a Sony TV that implemented this policy -- and the only way I could have complete silence was to port the TV through my stereo system (with a Hafler remote-controlled preamp) and deselect the TV during commercials.
Despite ReplayTV's claim that the 30-second skipover feature is "to skip past boring scenes in the show", the real incentive for putting that there is to skip over commercials -- a feature that seems to have disappeared from many top-of-the-line VCRs. I don't know why.
Given the 70K TiVo/ReplayTV systems out there versus the 100+ million televison sets, I don't think that the ad people or the TV people are too worried as yet. The attempts to make VCRs illegal failed, which meant that "time shifting" was made a fair use for private efforts. (The issue of "sharing" a show, perhaps with commercials deleted, is another question.) The set-top boxes don't have the capability of sharing -- the media isn't removable -- so I suspect that the broadcasters won't go down that road again.
When we see the maturation of ReplayTV/TiVo, though, I would expect some action to be taken by the people who perceive themselves as "gored" by the new technology.
Port scanning has its uses, but by a very limited number of people. Let's look at a few examples:
A number of ISP netadmins use port scanning to detect the presence of publically-offered services--the netadmin can then perform tests of those services to ensure they don't become smurf amplifiers or security holes. @Home looks for servers that operate in defiance of their Terms of Service (perhaps too hard). ORBS uses limited port scans to detect and document open mail relays.
Within corporate networks, netadmins regularly scan inside IP addresses looking for security holes -- particularly of publically accessible servers. Services offered are correlated with lists of possible problems, and the software examined to apply appropriate patches.
Some research depends on Internet-wide port scans to further worthwhile projects. For example, the "fingerprinting" of public servers provide statistics of what software is being used. A mapping project sponsored by NASA generates a sample of "working" systems by using a limited port probe -- I see this all the time in my firewall logs and traced down the project to find out just what was going on. (At some point, I will update my firewall filters to pass through the well-identified IP addresses of this activity, so that their research will reflect reality a bit better.)
Unfortunately, the good works that honest researchers (both pro and amateur) do is far outstripped by the number of people who use the "burgler tools" indiscriminately, or for nafarious purposes. Mass fingerprinting identifies systems ripe for root/admin compromise, or for potential denial of service if the wish arises to do so.
Another commenter said that [paraphrase] "a person checking doors to see if they are locked is suspicious in and of itself": it depends on who is doing the knob-rattling, and whether I know about it beforehand. Port scanning is just that, "knob-rattling." Most firewall appliances and software sold today will detect and block even "stealth" scans of their assigned IP addresses. As they should.
The sad part is that people who run port scanners are considered guilty until proven innocent of trying to commit an unsocial act. AS THEY SHOULD BE. This posture makes sense, because port scanning, like UCE/UBE, uses resources that the user of the port scanning software isn't paying for, and in all too many cases isn't desired by the receiver of the scan packets.
Are the legislators essentially just relying on the courts to strike down bad laws like this ? Surely after the CDA judgement there can't have
been much doubt that this was unconstitutional ?
(The following is directed at USA citizens only.)
The short answer:   yes.
Remember that the #2 "customer" of a legislator is the voter in his/her district. (The #1 customer, of course, is the donor to his/her election campaigns.) The legislator's customers measure the legislator by looking at his/her voting record, by looking at the laws the legislator got up and pushed to encourage passage, by looking at the speeches the legislator made for or against specific topics.
The voters in general and the contributors in particular don't help matters by identifying one or two issues that are "important" and "must be fixed now" whether the legislator agrees or not. (We have single-issue people here on/. so don't be smug.)
Notice that the Courts do not go back through legislative intent and say "The contribution from Senator Blowhard is what makes this bill unconstitutional." Pinning the unconstitutional tail on the donkey-rep is almost impossible for those people who want a life...and the press doesn't consider it enough of a story to dig on our behalf. (And frankly, as a journalist, I agree with the press on that matter.) Voters therefore can't recognize that their legislator is being ineffective on the issue, ineffective because said legislator is unwilling or unable to craft a law that meets the goal yet passes Constitutional muster.
In many respects, we voters have paid so much attention to "litmus tests" that we have forgotten that we are sending a person to Washington DC to decide on thousands of issues without getting a firm grasp on how that person will vote, let alone view the issues. We vote based on slogans, poll-directed speeches, appearance (think back to Kennedy v Nixon), and how Aunt Edna feels about the candidate. Not to mention how the candidate says s/he feels about our pet peeve.
So what? You're allowed to use copyrighted pics if it's for the purpose of criticism, commentary, news reporting, etc. It's fair use.
Like most exceptions, the fair-use laws imposes limits on the amount of material you may use for the purpose. This is why most news organizations obtain permission to use a picture in a publication before the publication goes to press. Ditto TV press in the use of non-in-house film.
In the case of criticism, the picture you purloined had damn well better be necessary in order for your criticism to hold up -- the "bar" is different from judge to judge, and the wise journalist/critic anticipates that he will get "Hang 'em Harriet" for a judge and selects and uses images accordingly.
I'm not sure what is the status of illegally distributed photographs vis a vis fair use. I'm sure, though, that Apple didn't provide permission, let alone credits, for the embargoed pictures that were shown on the Web site.
When you live on the cutting edge, expect to bleed.
Well, I'm really showing my age by saying this, but I worked on Network Graphics Protocol on the APRAnet in the early 1970s, with the results of my work and the work of others published as RFC 493 in 1974. Originally, NGP (as it was known in 1972) worked only with line segments; text and bitmaps were added after I had left the project.
The basics are simple: the drawing field is 65536 by 65536 virtual pixels, with the coordinates interpreted as an integral fraction (or scaled integer, if you prefer).
The RFC is not available online, but I have a copy as printed in the 1985 DDN Protocol Handbook.
Here is an interesting quote from RFC493: "When reason decends on the world, the TELNET negotiation mechanism (see NIC 15372) will be used to establish the willingness to transmit graphics information (DO, DONT, WILL, WONT, GRAPHICS) and a subnegotiation transmission will transmit the socket number [of the independent graphics connection]. In the case of an intelligent graphics terminal attached to a TIP [terminal interface processor], the TIP TELNET responds to the negotiation and establishes the connections."
Some additional details: there is a Z-axis, or intensity, specification in the primatives. The Microsoft Windows concept of different co-ordinate systems may well have had its roots in this 30-year-old protocol, because NGP has one system for vectors, another system for text, and a third system for areas.
The protocol also allowed for input devices. You know this predates mice from this quote: "The state of a coordinate device is a pair of coordinates in the screen coordinate system. These coordinates could be derived from a tablet and stylus, from a light pen, from two knobs [emphasis added], from a keyboard (by typing in values, or using a keyboard-propelled cursor) or whatever." The invention of the mouse was to take the "two knobs" and put them in a housing that could be moved by the hand.
If you are interested in reading this old, old RFC, I could be talked into scanning the RFC from the printed copy and posting it on my web site. It's a government publication.
RIAA and MPAA: Turnaround is fair play
on
Hacker Crackdown?
·
· Score: 1
So the RIAA and MPAA are now looking at distributors and "enablers" of illegal materials as fair game. Good.
Assuming the RIAA and MPAA prevail, then I submit that the precedent thus created could be used against them in actions against the distribution and exhibition of hate speech in music and movies.
I like Richard Stallman, in small quantities. He had great ideas. This is not one of them.
Richard makes it clear that when he says "proprietary software developers" he is thinking about the Microsofts, the Computer Associates, the Symantics of the world. He forgets there is another class of proprietary software developer, the in-house developer. This is the guy working for a company (most traditionally a brick-and-morter, although some dot-coms fit this bill) in which some other service is their bread-and-butter. The company wishes to use computer technology internally to gain a competitive edge over their competition.
Now, the GNU License discourages the in-house programmer to make changes to GPL code, or to link to GPL libraries, because according to the license that programmer has to publish the changes. So the programmer does all the work, and then gives the fruit of the work to the competition. Nope -- he will be forced into a commercial solution.
No one cries when "the victim" is an insurance company, but how about the coffee roaster who is trying to use computers to control coffee roasting to order?
If you put too many barriers on the use of free [speech] software, it will force people to consider alternatives...and in the worst case some very nifty stuff won't happen.
Then where will Richard Stallman get his next quarter-million-dollar grant?
When you look at the progression of programming languages over the years, you see a growth in complexity followed by a simplification and maturation. This cycle, I believe, will continue.
The B language is a perfect example. It's atomic elements mapped one-for-one with the DEC PDP-7 instruction set, and included interesting shorthand that sped development. The C language fixed some of the growth pains of B; the standard mandated strong typing so that the compiler could do better what "lint(1)" tried to do. C++ tried to extend the C syntax into the object world, with some consequences good and bad.
What I see, though, is the creation of new languages to solve specific problems in ways that are natural to the particular problem-solver. You see this with business languages that abstract several thousand lines of COBOL code in a single statement. The further abstraction makes writing certain code easier, faster, and more bug-free.
Emphasis needs to be increased on program accuracy. Debugging has been bolted on for years; it's time for significant debugging aids to be included in languages.
When law enforcement obtains a court order to monitor your mail, they can either look only on the outside of the envelope or have the authority to open and read your mail. Likewise, the difference between a wiretap and a "pen register" order is that the former allows law enforcement to listen to the conversations, while a pen register order (or trap-and-trace order) is limited to capturing the digits of the party you are calling.
In the mail case, there is a definite barrier between the address information and the content, so limiting law enforcement to the proper level of monitoring is fairly easy. In the telephone-tapping case, though, the growing use of voice-response systems that accept DTMF digits makes it harder for law enforcement to avoid capturing content -- and that content can be my bank account number and the PIN associated with it so that someone tapping my line with a pen-register order could access the account without due process.
On the Internet, the intrusion goes beyond that of the pen-register tap. With the telephone company, the telephone switch can isolate one line from the rest of the lines in the central office. There is no such isolation in the Internet for e-mail. Software would have to monitor EVERYTHING.
It's the requirement about looking at everything, even if you only want address information, that make Carnivore such a problem.
The solution would be for the Congress to pass a law that would require all electronic mail programs to encrypt all messages so that a pen-register order is guaranteed to capture only address information.
It starts with an electronic equivalent of your physical address. It morphs into a "location-independent address" similar to the location-independent telephone numbers that the phone companies are working towards. Once you are stuck with a single address, no matter where you live, you now have in place a universal identifier.
How many places require you to provide a mailing address in order to receive services? To purchase goods? "It's so you are elegibe for the warranty."
The legal processes are already in place. The US Fifth Amendment does not cover your name and your address -- you can be forced to give both. What databases wouldn't have your address?
You can bet that the United States Postal Service will learn from the mistakes made by the Social Security Administration -- the number space will be large enough so that there would be no reuse of addresses for at least 300 years. At birth, each surviving baby would receive its own unique address -- after all, marriages break up, parents die, and the child might end up in an orphanage, so if mail is to reach each and every person, then each person needs a unique address don't they?
We may look back at today as "the good ol' days"...
Just a short note: the sad state of subscriber loops (the wires between your home and the central office) still are a problem. That's why you read about people not getting fast modem speeds with either V.34 or V.90 -- the loop quality just isn't up to it.
I myself see V.92 as having a diminishing benefit. Upload rate is capped at 48,000 bits/s. Download rate is identical to V.90.
Is this any reason to go through yet another round of incompatibilities between modem brands?
I was amused by the tripe that Bell labs was putting forward as the "history" of UNIX. Note that the focus was on Bell Labs, and less on the idea that Unix was in reality a skunk works project to build a word processing package from scrap equipment. ("There was this PDP-7 gathering dust in the closet..." is one line I remember.) The second system to host UNIX was an IBM System 360. Don't remember the exact model.
No mention on the Labs page of the "B" programming language, developed as a "high level assembler" to speed the development of the project so that the bosses wouldn't get too upset. What makes the above claim believable is when you take the PDP-7 instruction set and compare it to the operations set in the original K&R C language set, you find almost a one-for-one match, including indirection! Many of the other features of Unix which makes it so popular are there not only because they were good ideas, but they had to get something working quickly, and not spend a lot of time debugging. Code reuse? Speeds up debug. Pipes? String together what you have, don't reinvent the wheel. The shell? Interpreted code may run slow, but it is much faster to write and debug. Speed of implementation was paramount when you were doing something that, er, you weren't supposed to be doing...
As for the eventual audience of this skunk-works project, there is a legand (which may or may not be true) that the system was to be used by lawyers for word-processing stuff -- it was a cheaper alternative to buying a word-processor system like the one sold by NBI. Anyone recall the Writer's Workbench that used to ship with SCO Unix and other Unix systems? Now you know.
Creative could, if it wishes, provide a library of closed-source functions (well-documented) that would expose only those interfaces needed to talk to the outside environment, while keeping the intellectual property hidden behind a veil.
The advantage to Creative is that they could now concentrate on getting the display routines correct without giving away IP and without having to add staff that knows a number of target operating systems. The advantage to the Linux and FreeBSD communities is that the respective communities can deal with any OS interface problems using the normal channels.
The added bonus to Creative is that they now have a kit to provide to other OS vendors (BeOS, MacOS on Intel, QNX, even Bell Labs if they ever want to get back into the operating system game) that reduces the load on everyone.
Frankly, I'm getting tired of the "Victory or Death!" attitude that permeates portions of the Open Source Movement. Open source has its place. Closed source has its place, too. Let's be engineers and blend the best of the two concepts, instead of religious nuts more interested in the Grail of the Week.
There most certantly *IS* SSMTP. It's supported by the postfix+TLS patch. Most mailers don't include it because of legal issues RE: RSA and export restrictions.
Port number, please. I don't find any secure version of SMTP in the ISI list of well-known ports.
Summary: just how much does the Carnivore box monitor? Does it look only at IMAP/POP2/POP3/SMTP traffic, or is its charter far, far broader to capture at least the endpoints of communciations using other modes of operation? Does this mean that the FBI therefore has a trace of all your activity available to it? The rest of this article looks at just how much the FBI would have to monitor in order to trace all possible mail traffic conduits.
The telephone industry has been told they have to design switchgear to make ubiquitious wiretaps easier. That mandate has not, to date, been extended to Internet Service Providers...but I can see where the ISP business will be nailed in just this way. Unfortunately for law enforcement, such a law would only help them catch the really, really, stupid criminal or the casual criminal -- the hard-core types would enlist the aid of cybercriminals [no, not hacker you dimwit] to help them hide their tracks.
Frankly, the Internet marketplace provides a number of opportunities to thwart this sort of stuff. Some examples:
Etherswitches instead of hubs: If ISPs were to rip out all standard hubs and replace them with Etherswitches, it makes it far more difficult for the FBI to find a tap point. An added bonus is that your internal connectivity improves remarkably, and you will find it far less likely (using 100-Base T switches) to run out of bandwidth inside.
Clusters for mail: By using cluster technology, where you use a group of single-CPU servers instead of a single multi-CPU server and a disk array, you improve your mail reliability and break the mail path into enough segments that a single-port sniffer won't do the job. The business reason to do this, too, is to increase the reliability of mail carriage -- particularly if each CPU supported both client and remote SMTP as well as POP2, POP3, and IMAP. If one CPU goes down, the other three can take up the slack until the one CPU is fixed. Properly designed redundent data arrays are in and of themselves immune to single-point failure.
Webmail: This speaks for itself. The cops would have to be monitoring Web accesses as well as the seven or so mail protocols. Not only that, but the FBI box would have to be able to tell the difference between accesses to a mail server and accesses to, say, SlashDot. Webmail itself is easier to use than most Mail User Agents. The downside of Webmail is that the FBI could then monitor the Webmail service in some way...but there are plenty of free mail services out there. For a pen-and-trace tap, though, the free mail services have well-known Internet addresses, but the ability to trace mail through the free services would be far more difficult. Indeed, how do you differentiate between mail to a remote perp and mail to an innocent party? You would have to be able to interpret the content of Web traffic -- and that runs afoul of the content restrictions on pen-and-trace.
TELNET: Then there is the use of TELNET-base mail services and TELNET tunnelling. Early ARPAnet users used TELNET to access the native mail systems on the hosts, and by prior agreement decided which hosts would carry what threads. Does the FBI capture every keystroke of a TELNET session to determine whether it "looks" like mail?
FTP: Everyone is so hung on on SMTP/POP3 that they forget that for years significant communications have been done using FTP and other data-exchange protocols. See The Oddessy Files for a description how Authur Clarke and Bill Hyman exchanged files as mail using RCPM systems. With FTPS/990 and FTPS-data/989 the only option that law enforcement would have is a "pen-and-trace" to FTP sites, or an FTPD running on an end-point machine.
Private-port traffic: Just because the IETF publishes a list of well-known ports doesn't mean that perps have to use those numbers. There are 65534 port numbers to choose from, and the numbers do not have to be consistant from host to host. Couple this with a network of proxies and relays sprinkled around the world (remember, there are countries where the FBI has no entry) and the only tool available to nail the perp would be RICO -- if they could prove it. Does this mean that the FBI would pen-and-trace EVERY SINGLE CONNECTION? Does it mean it has to monitor all DNS lookups to see if a DNS randomizer is steering a particular domain name to multiple addresses? Does the pen-and-trace also extend to DNS lookups in general? Or is it because DNS would be considered by the courts as "address information" that the content of DNS lookups would be captured?
SSL [VPN]: Just because I'm using an ISP for Internet access doesn't mean that I use that ISP for mail. I could be tunnelling to another site, or a chain of sites, using VPN (IPIP tunnels encrypted with SSL) to obtain mail. Does the FBI intend to sniff out my tunnel usage and place Carnivore boxes at every possible location? Would the courts stand still for such activity?
SSL [POP3S/995, TELNETS/992]: One of the concerns of the FBI was what happened when encryption became widespread. Now we know one of the reasons why. [Interesting that there is no secure SMTP available -- is it because sendmail and other MTAs don't want to support it?]
SSL [HTTPS, especially Webmail]: This enhances the security of Web-based mail, where available. I have Webmail that understands and uses SSL, which means that I can avoid being snooped between client and my mail server, wherever that mail server is. Coupled with the number of Webmail services, it would take a large number of boxes to trace the activities of someone who has really learned how to use a large, large number of Webmail services. Building a private webmail service from readily-available tools, like Microsoft FrontPage, would be a snap...and the result would be something that could be used as a mail-relay agent that would thwart pen-and-trace wiretaps.
Encryption in general: In many cases, law enforcement isn't all that interested in the content of the messages, but instead are interested in traffic patterns. "Pen and trace" taps are far easier for law enforcement to get, and they use it to identify targets for more traditional search warrants. The only way to avoid such traffic analysis is to use an off-short remailer to relay your traffic. In time, though, the use of a remailer service will be used by prosecutors as evidence that you, the citizen, have something to hide. Encrypting the body of your message, then, does something for you only when you really have something illegal to hide and you have really attracted the attention of law enforcement.
This is not intended to be a primer on how to "get around" the FBI Carnivore box. This is intended to show (a) how difficult the task is to monitor all mail given current technology, and (b) to show how combating the technology already in place may cause privacy concerns far greater than mentioned already.
The monitoring of paper mail is, by comparison, a far easier task: you have a handful of choke points (USPS, FedEx, UPS, DHL, and so forth) who need to be in the good graces of law enforcement to do their job. The monitoring of fax and modem traffic is done using pen-and-trace wiretaps, recognizing the unique wideband signals to identify the difference. (Did you know it's extrememly difficult -- read "expensive" -- to extract content from V.34 and V.90 traffic from a tap?)
In contrast, once you get access to the digital Internet. how do you monitor ALL the ways to exchange mail?
My question, which was not covered on the Web site nor on any story I've read to date, is what the FBI expects of the ISP that has one of these things put on its site.
First, I've been writing reviews since 1984, when I purchased my first Compaq computer -- the sewing-machine version that couldn't take a hard drive. Yes, the lure to do reviews was "free" software...but I quickly moved to hardware reviews where you don't get to keep the product at all.
Reviewing platforms, or reviewing software cross-platform, is some of the roughest reviewing possible. Think about reviewing two different operas on two different stages and you get the idea.
The problem with all the reviews I've read that attempt to compare the performance of Linux and NT is that the assumptions behind the test methodology are geared toward either the Linux or NT model. That means you are trying to compare apples and oranges. The two are completely different beasts. Complicating the problem is that much of the performance testing methodology developed for the computing industry is centered around Unix -- very centered around Unix.
The most unbiased performance test suites around are the SPECmark series. I learned the hard way just how Unix-centric the SPECmark series of tests are when I tried to port them to the Macintosh OS -- indeed, I never finished the job. Indeed, I can't even see how to port the SPECmarks to the Windows environment because of the large number of Unix-isms built into the benchmarks. The reason? The benchmarks are actual live real working applications, designed to do a job and not just fiddle bits to eat up resources.
While I agree that the most unbiased reviews come from users, all the vast majority of them can tell you is that "Hey, it worked [didn't work] for me for what I do!" The vast majority of users don't have a clue how to do a structured evaluation of software or hardware...even slash-dot readers. That's why I was able to make a comfortable living for about ten years, writing reviews.
The only review methodology that might make sense is to develop a task, and have two teams configure systems to perform that task. Even then, you will run into variances because the teams may have differing knowledge levels of the systems they are trying to tune for the task. This is the big problem in SpecWeb marks, judging from the reports I've read lately on their sites.
Will there be a fair review? Right now, I think the issue is in doubt.
To the subject of "pay for play" -- in the fifteen years I have been reviewing stuff, I have been offered a number of bribes. None of the companies trying to bribe me ever met my price; hell, they never came close! Other companies have threatened me with lawsuits for what I wrote. None have gone to court, and all but one was settled out of court in my favor. (That one, I admitted that I did the review wrong, and the magazine and I came up with a fix that satisfied everyone.)
Of course I'll eat their food, and of course I'll listen to the PR flacks. That doesn't mean that I'll write a review based on what flacks tell me.
As a founding member of the Internet Press Guild (www.netpress.org) I subscribe to a canon of ethics that require me to write what I experience with products, not what someone tells me to day. That includes editors -- there has been more than one article I've pulled because an editor disagreed with my findings. IT'S MY NAME. Stephen Satchell Satchell Evaluations
I have the dubious honor of being the first paying customer for Nevada Bell DSL -- now a part of SBC Advanced Internet Services -- in Northern Nevada (the Reno area). My service was installed over a year ago. At the time, I elected to go with "Nevada Bell Internet," a re-brand of PacBell Internet...and an unwanted step-child it was, too.
In the early days, NBI was using bridging mode instead of PPPoE, so it was no problem at all to shift the install from the Windows 98 system I stuck in front of the installer to the Red Hat Linux system that functions as my NAT firewall.
Because of a number of issues documented elsewhere (dslreports.com) I fired NBI and went with another ISP, a then-local company called Pyramid.Net.
One of the reasons I went with Pyramid.Net was the promise from the operator that they would continue to use bridging mode, instead of moving to something like PPPoE. They have kept their promise.
Pyramid.Net is not the only "partner" to SBC to provide briding mode access, which is a true always-on service (as opposed to the necessity of logging in a la PPPoE) with a surprisingly high availability.
Moral of this tale: go with a "partner", not the [A-Za-z]+ Bell Internet company.
The newsgroup comp.dcom.xdsl regularly carries postings from people with horror stories. Note particular those stories told by Bell Atlantic customers...
OK, I took a once-over through the document (I actually looked at the Word one) and was unimpressed. Most of my feelings were expressed by others, so I won't repeat them here. As far as being able to do system-level code, it has a number of problems. (Of course, who in their right minds would code an OS, for example, in C++?)
The big problem I see, though, is that people who are doing telecom protocols are going to find tough sledding in using McLanguage to build packets.
What I want to know is, exactly WHO is the audience for this new, non-portable language?
Just an observation: wasn't the whole idea of the formulation of the GPL to mimic the commercial shrink-wrap license?
That would be the root of the argument made by an Anonymous Coward earlier in this thread, that the collapse of the GPL in its current form would weaken all shrinkwrap agreements.
Why bring up the ASP? I suspect that if the GPL falls, so will the shareware license agreements, and pretty much for the same reasons: privity. Remember, shareware is meant to be distributed by the buying customer to other third parties.
One way to insure privity of subsequent users of the GPL'ed code is to include a reference to the GPL and a further requirement that any modification leave the reference intact within each file of the source code. This would include all header files, make files, configuration files (now you know the real reason that they all allow comments), as well as a LICENSE file.
Many packages already have license terms embedded in the source, but by no means ALL the source.
Because the source is the item being licensed by the GPL, having the license as part of the source at the top of the source pretty well puts any downstream user on notice.
I wonder if Douglas Adams had read the book The Decline and Fall of Practically Everybody by Will Cuppy?
The book consists of a series of essays on well-known figures of history, with the main text giving the (usually) straight dope and the many, many footnotes (a Cuppy trademark) making fun of it all. Underneath the footnote humor was a wonderful set of irreverent observations, some of which struck me as fodder for master thesis topics for historian candidates.
Failure, presented in a funny way.
As I recall, the book was on the USA best-seller list for weeks. I didn't see it until much later (in paperback). If my history classes had been taught in this way, I might have been hooked on history instead of bits.
I would like to point out that the utility companies -- electric, water, and other less interesting -- have looked at what it will take to provide very wideband server. Some have announced the deployment of huge-pipe services.
You can bet that Sprint, AT&T, and so forth will have to pay to use that bandwidth. Indeed, PacBell thought they had bought bandwidth (but the deal fell through) so packets routed through that peering arrangement were dropped on the floor. From Nevada, I was blocked from most sites in Northern California, and was forced to set up a router of my own to divert traffic from PacBell's network to Concentric's network. (Lots of fun, and at 3 AM to boot.)
Nothing stops a company from providing wideband transport and competing with the Big 5.
Slashdot Mirror
If you could compress the standard 30-second adverts by a factor of 10, you get the three-second BlipVerts "invented" by George Stone, Rocky Morton, and Annabel Jnakel. Remember the original idea: "BlipVerts happen so fast, they're over and embedded in viewers' minds before they have a chance to channel-switch."
The updated patent filing would read, "BlipVerts happen so fast, they're over and embedded in viewers' minds before they have a chance to fast-forward past them."
Couple that with the research that has been done on driver reaction-time and you can see that editing out commercials on-the-fly would be virtually impossible; indeed, you would need the electronic equivalent of an A/B Roll Editor to get rid of the pesky things. For those shows with a high beer-drinking quotient (like football games, guy), the BlipVerts could extend to six seconds because the alcohol-sotted viewer would need several seconds to find the button, let alone press it enough to make contact. So says the driver-reaction studies over the past 30 or so years.
The movie Max Headroom: 20 Minutes Into the Future (later released to video as Max Headroom, The Original Story) postulated a solution that assumed real-time viewing. Interesting that the same solution would apply to the easy time-shifting that the TiVo and ReplayTV enable.
(To show just how prescient the writers of the original script were, just how soon do you think it will happen that a television network executive will be able to propose this solution to a knotty scheduling war: "We can go porno early.")
I sympathize with your plight. Having gone through a similar issue with Pacific Bell Internet earlier in the year, I know how frustrating it can be. In short, the service sucked.
My problems were not on cable modem service, but DSL. I was able to locate and strike a deal with a local ISP that was a "DSL partner" to switch the ISP provisioning from PBI to the local ISP.
It is experiences like yours that keeps me working toward ISP equal access on cable. When the ISPs don't have a captive market, they tend to pay attention to maintenance. A monopoly, especially one that doesn't have to answer to anyone except possibly a class-action lawsuit, tends toward cavilier toward the finer stuff. Case in point: the only reason FTP access would be down more than a couple of days is because no one is working on it. I've had FTP servers go down on me, and I was able to bring them back up in hours, not days and not especially a month.
As long as the FCC allows monopoly ISP service for cable modems, we will continue to see complaints like yours.
Despite ReplayTV's claim that the 30-second skipover feature is "to skip past boring scenes in the show", the real incentive for putting that there is to skip over commercials -- a feature that seems to have disappeared from many top-of-the-line VCRs. I don't know why.
Given the 70K TiVo/ReplayTV systems out there versus the 100+ million televison sets, I don't think that the ad people or the TV people are too worried as yet. The attempts to make VCRs illegal failed, which meant that "time shifting" was made a fair use for private efforts. (The issue of "sharing" a show, perhaps with commercials deleted, is another question.) The set-top boxes don't have the capability of sharing -- the media isn't removable -- so I suspect that the broadcasters won't go down that road again.
When we see the maturation of ReplayTV/TiVo, though, I would expect some action to be taken by the people who perceive themselves as "gored" by the new technology.
A number of ISP netadmins use port scanning to detect the presence of publically-offered services--the netadmin can then perform tests of those services to ensure they don't become smurf amplifiers or security holes. @Home looks for servers that operate in defiance of their Terms of Service (perhaps too hard). ORBS uses limited port scans to detect and document open mail relays.
Within corporate networks, netadmins regularly scan inside IP addresses looking for security holes -- particularly of publically accessible servers. Services offered are correlated with lists of possible problems, and the software examined to apply appropriate patches.
Some research depends on Internet-wide port scans to further worthwhile projects. For example, the "fingerprinting" of public servers provide statistics of what software is being used. A mapping project sponsored by NASA generates a sample of "working" systems by using a limited port probe -- I see this all the time in my firewall logs and traced down the project to find out just what was going on. (At some point, I will update my firewall filters to pass through the well-identified IP addresses of this activity, so that their research will reflect reality a bit better.)
Unfortunately, the good works that honest researchers (both pro and amateur) do is far outstripped by the number of people who use the "burgler tools" indiscriminately, or for nafarious purposes. Mass fingerprinting identifies systems ripe for root/admin compromise, or for potential denial of service if the wish arises to do so.
Another commenter said that [paraphrase] "a person checking doors to see if they are locked is suspicious in and of itself": it depends on who is doing the knob-rattling, and whether I know about it beforehand. Port scanning is just that, "knob-rattling." Most firewall appliances and software sold today will detect and block even "stealth" scans of their assigned IP addresses. As they should.
The sad part is that people who run port scanners are considered guilty until proven innocent of trying to commit an unsocial act. AS THEY SHOULD BE. This posture makes sense, because port scanning, like UCE/UBE, uses resources that the user of the port scanning software isn't paying for, and in all too many cases isn't desired by the receiver of the scan packets.
Are the legislators essentially just relying on the courts to strike down bad laws like this ? Surely after the CDA judgement there can't have been much doubt that this was unconstitutional ?
(The following is directed at USA citizens only.)
The short answer:   yes.
Remember that the #2 "customer" of a legislator is the voter in his/her district. (The #1 customer, of course, is the donor to his/her election campaigns.) The legislator's customers measure the legislator by looking at his/her voting record, by looking at the laws the legislator got up and pushed to encourage passage, by looking at the speeches the legislator made for or against specific topics.
The voters in general and the contributors in particular don't help matters by identifying one or two issues that are "important" and "must be fixed now" whether the legislator agrees or not. (We have single-issue people here on /. so don't be smug.)
Notice that the Courts do not go back through legislative intent and say "The contribution from Senator Blowhard is what makes this bill unconstitutional." Pinning the unconstitutional tail on the donkey-rep is almost impossible for those people who want a life...and the press doesn't consider it enough of a story to dig on our behalf. (And frankly, as a journalist, I agree with the press on that matter.) Voters therefore can't recognize that their legislator is being ineffective on the issue, ineffective because said legislator is unwilling or unable to craft a law that meets the goal yet passes Constitutional muster.
In many respects, we voters have paid so much attention to "litmus tests" that we have forgotten that we are sending a person to Washington DC to decide on thousands of issues without getting a firm grasp on how that person will vote, let alone view the issues. We vote based on slogans, poll-directed speeches, appearance (think back to Kennedy v Nixon), and how Aunt Edna feels about the candidate. Not to mention how the candidate says s/he feels about our pet peeve.
Even people who read /.
Like most exceptions, the fair-use laws imposes limits on the amount of material you may use for the purpose. This is why most news organizations obtain permission to use a picture in a publication before the publication goes to press. Ditto TV press in the use of non-in-house film.
In the case of criticism, the picture you purloined had damn well better be necessary in order for your criticism to hold up -- the "bar" is different from judge to judge, and the wise journalist/critic anticipates that he will get "Hang 'em Harriet" for a judge and selects and uses images accordingly.
I'm not sure what is the status of illegally distributed photographs vis a vis fair use. I'm sure, though, that Apple didn't provide permission, let alone credits, for the embargoed pictures that were shown on the Web site.
When you live on the cutting edge, expect to bleed.
Well, I'm really showing my age by saying this, but I worked on Network Graphics Protocol on the APRAnet in the early 1970s, with the results of my work and the work of others published as RFC 493 in 1974. Originally, NGP (as it was known in 1972) worked only with line segments; text and bitmaps were added after I had left the project.
The basics are simple: the drawing field is 65536 by 65536 virtual pixels, with the coordinates interpreted as an integral fraction (or scaled integer, if you prefer).
The RFC is not available online, but I have a copy as printed in the 1985 DDN Protocol Handbook.
Here is an interesting quote from RFC493: "When reason decends on the world, the TELNET negotiation mechanism (see NIC 15372) will be used to establish the willingness to transmit graphics information (DO, DONT, WILL, WONT, GRAPHICS) and a subnegotiation transmission will transmit the socket number [of the independent graphics connection]. In the case of an intelligent graphics terminal attached to a TIP [terminal interface processor], the TIP TELNET responds to the negotiation and establishes the connections."
Some additional details: there is a Z-axis, or intensity, specification in the primatives. The Microsoft Windows concept of different co-ordinate systems may well have had its roots in this 30-year-old protocol, because NGP has one system for vectors, another system for text, and a third system for areas.
The protocol also allowed for input devices. You know this predates mice from this quote: "The state of a coordinate device is a pair of coordinates in the screen coordinate system. These coordinates could be derived from a tablet and stylus, from a light pen, from two knobs [emphasis added], from a keyboard (by typing in values, or using a keyboard-propelled cursor) or whatever." The invention of the mouse was to take the "two knobs" and put them in a housing that could be moved by the hand.
If you are interested in reading this old, old RFC, I could be talked into scanning the RFC from the printed copy and posting it on my web site. It's a government publication.
So the RIAA and MPAA are now looking at distributors and "enablers" of illegal materials as fair game. Good.
Assuming the RIAA and MPAA prevail, then I submit that the precedent thus created could be used against them in actions against the distribution and exhibition of hate speech in music and movies.
What will be their defense, then?
I like Richard Stallman, in small quantities. He had great ideas. This is not one of them.
Richard makes it clear that when he says "proprietary software developers" he is thinking about the Microsofts, the Computer Associates, the Symantics of the world. He forgets there is another class of proprietary software developer, the in-house developer. This is the guy working for a company (most traditionally a brick-and-morter, although some dot-coms fit this bill) in which some other service is their bread-and-butter. The company wishes to use computer technology internally to gain a competitive edge over their competition.
Now, the GNU License discourages the in-house programmer to make changes to GPL code, or to link to GPL libraries, because according to the license that programmer has to publish the changes. So the programmer does all the work, and then gives the fruit of the work to the competition. Nope -- he will be forced into a commercial solution.
No one cries when "the victim" is an insurance company, but how about the coffee roaster who is trying to use computers to control coffee roasting to order?
If you put too many barriers on the use of free [speech] software, it will force people to consider alternatives...and in the worst case some very nifty stuff won't happen.
Then where will Richard Stallman get his next quarter-million-dollar grant?
When you look at the progression of programming languages over the years, you see a growth in complexity followed by a simplification and maturation. This cycle, I believe, will continue.
The B language is a perfect example. It's atomic elements mapped one-for-one with the DEC PDP-7 instruction set, and included interesting shorthand that sped development. The C language fixed some of the growth pains of B; the standard mandated strong typing so that the compiler could do better what "lint(1)" tried to do. C++ tried to extend the C syntax into the object world, with some consequences good and bad.
What I see, though, is the creation of new languages to solve specific problems in ways that are natural to the particular problem-solver. You see this with business languages that abstract several thousand lines of COBOL code in a single statement. The further abstraction makes writing certain code easier, faster, and more bug-free.
Emphasis needs to be increased on program accuracy. Debugging has been bolted on for years; it's time for significant debugging aids to be included in languages.
When law enforcement obtains a court order to monitor your mail, they can either look only on the outside of the envelope or have the authority to open and read your mail. Likewise, the difference between a wiretap and a "pen register" order is that the former allows law enforcement to listen to the conversations, while a pen register order (or trap-and-trace order) is limited to capturing the digits of the party you are calling.
In the mail case, there is a definite barrier between the address information and the content, so limiting law enforcement to the proper level of monitoring is fairly easy. In the telephone-tapping case, though, the growing use of voice-response systems that accept DTMF digits makes it harder for law enforcement to avoid capturing content -- and that content can be my bank account number and the PIN associated with it so that someone tapping my line with a pen-register order could access the account without due process.
On the Internet, the intrusion goes beyond that of the pen-register tap. With the telephone company, the telephone switch can isolate one line from the rest of the lines in the central office. There is no such isolation in the Internet for e-mail. Software would have to monitor EVERYTHING.
It's the requirement about looking at everything, even if you only want address information, that make Carnivore such a problem.
The solution would be for the Congress to pass a law that would require all electronic mail programs to encrypt all messages so that a pen-register order is guaranteed to capture only address information.
Can you imagine the howls?
How many places require you to provide a mailing address in order to receive services? To purchase goods? "It's so you are elegibe for the warranty."
The legal processes are already in place. The US Fifth Amendment does not cover your name and your address -- you can be forced to give both. What databases wouldn't have your address?
You can bet that the United States Postal Service will learn from the mistakes made by the Social Security Administration -- the number space will be large enough so that there would be no reuse of addresses for at least 300 years. At birth, each surviving baby would receive its own unique address -- after all, marriages break up, parents die, and the child might end up in an orphanage, so if mail is to reach each and every person, then each person needs a unique address don't they?
We may look back at today as "the good ol' days"...
Just a short note: the sad state of subscriber loops (the wires between your home and the central office) still are a problem. That's why you read about people not getting fast modem speeds with either V.34 or V.90 -- the loop quality just isn't up to it.
I myself see V.92 as having a diminishing benefit. Upload rate is capped at 48,000 bits/s. Download rate is identical to V.90.
Is this any reason to go through yet another round of incompatibilities between modem brands?
No mention on the Labs page of the "B" programming language, developed as a "high level assembler" to speed the development of the project so that the bosses wouldn't get too upset. What makes the above claim believable is when you take the PDP-7 instruction set and compare it to the operations set in the original K&R C language set, you find almost a one-for-one match, including indirection! Many of the other features of Unix which makes it so popular are there not only because they were good ideas, but they had to get something working quickly, and not spend a lot of time debugging. Code reuse? Speeds up debug. Pipes? String together what you have, don't reinvent the wheel. The shell? Interpreted code may run slow, but it is much faster to write and debug. Speed of implementation was paramount when you were doing something that, er, you weren't supposed to be doing...
As for the eventual audience of this skunk-works project, there is a legand (which may or may not be true) that the system was to be used by lawyers for word-processing stuff -- it was a cheaper alternative to buying a word-processor system like the one sold by NBI. Anyone recall the Writer's Workbench that used to ship with SCO Unix and other Unix systems? Now you know.
Creative could, if it wishes, provide a library of closed-source functions (well-documented) that would expose only those interfaces needed to talk to the outside environment, while keeping the intellectual property hidden behind a veil.
The advantage to Creative is that they could now concentrate on getting the display routines correct without giving away IP and without having to add staff that knows a number of target operating systems. The advantage to the Linux and FreeBSD communities is that the respective communities can deal with any OS interface problems using the normal channels.
The added bonus to Creative is that they now have a kit to provide to other OS vendors (BeOS, MacOS on Intel, QNX, even Bell Labs if they ever want to get back into the operating system game) that reduces the load on everyone.
Frankly, I'm getting tired of the "Victory or Death!" attitude that permeates portions of the Open Source Movement. Open source has its place. Closed source has its place, too. Let's be engineers and blend the best of the two concepts, instead of religious nuts more interested in the Grail of the Week.
Port number, please. I don't find any secure version of SMTP in the ISI list of well-known ports.
Summary: just how much does the Carnivore box monitor? Does it look only at IMAP/POP2/POP3/SMTP traffic, or is its charter far, far broader to capture at least the endpoints of communciations using other modes of operation? Does this mean that the FBI therefore has a trace of all your activity available to it? The rest of this article looks at just how much the FBI would have to monitor in order to trace all possible mail traffic conduits.
The telephone industry has been told they have to design switchgear to make ubiquitious wiretaps easier. That mandate has not, to date, been extended to Internet Service Providers...but I can see where the ISP business will be nailed in just this way. Unfortunately for law enforcement, such a law would only help them catch the really, really, stupid criminal or the casual criminal -- the hard-core types would enlist the aid of cybercriminals [no, not hacker you dimwit] to help them hide their tracks.
Frankly, the Internet marketplace provides a number of opportunities to thwart this sort of stuff. Some examples:
This is not intended to be a primer on how to "get around" the FBI Carnivore box. This is intended to show (a) how difficult the task is to monitor all mail given current technology, and (b) to show how combating the technology already in place may cause privacy concerns far greater than mentioned already.
The monitoring of paper mail is, by comparison, a far easier task: you have a handful of choke points (USPS, FedEx, UPS, DHL, and so forth) who need to be in the good graces of law enforcement to do their job. The monitoring of fax and modem traffic is done using pen-and-trace wiretaps, recognizing the unique wideband signals to identify the difference. (Did you know it's extrememly difficult -- read "expensive" -- to extract content from V.34 and V.90 traffic from a tap?)
In contrast, once you get access to the digital Internet. how do you monitor ALL the ways to exchange mail?
It isn't much.
My question, which was not covered on the Web site nor on any story I've read to date, is what the FBI expects of the ISP that has one of these things put on its site.
Perhaps a good Boardwatch article?
First, I've been writing reviews since 1984, when I purchased my first Compaq computer -- the sewing-machine version that couldn't take a hard drive. Yes, the lure to do reviews was "free" software...but I quickly moved to hardware reviews where you don't get to keep the product at all.
Reviewing platforms, or reviewing software cross-platform, is some of the roughest reviewing possible. Think about reviewing two different operas on two different stages and you get the idea.
The problem with all the reviews I've read that attempt to compare the performance of Linux and NT is that the assumptions behind the test methodology are geared toward either the Linux or NT model. That means you are trying to compare apples and oranges. The two are completely different beasts. Complicating the problem is that much of the performance testing methodology developed for the computing industry is centered around Unix -- very centered around Unix.
The most unbiased performance test suites around are the SPECmark series. I learned the hard way just how Unix-centric the SPECmark series of tests are when I tried to port them to the Macintosh OS -- indeed, I never finished the job. Indeed, I can't even see how to port the SPECmarks to the Windows environment because of the large number of Unix-isms built into the benchmarks. The reason? The benchmarks are actual live real working applications, designed to do a job and not just fiddle bits to eat up resources.
While I agree that the most unbiased reviews come from users, all the vast majority of them can tell you is that "Hey, it worked [didn't work] for me for what I do!" The vast majority of users don't have a clue how to do a structured evaluation of software or hardware...even slash-dot readers. That's why I was able to make a comfortable living for about ten years, writing reviews.
The only review methodology that might make sense is to develop a task, and have two teams configure systems to perform that task. Even then, you will run into variances because the teams may have differing knowledge levels of the systems they are trying to tune for the task. This is the big problem in SpecWeb marks, judging from the reports I've read lately on their sites.
Will there be a fair review? Right now, I think the issue is in doubt.
To the subject of "pay for play" -- in the fifteen years I have been reviewing stuff, I have been offered a number of bribes. None of the companies trying to bribe me ever met my price; hell, they never came close! Other companies have threatened me with lawsuits for what I wrote. None have gone to court, and all but one was settled out of court in my favor. (That one, I admitted that I did the review wrong, and the magazine and I came up with a fix that satisfied everyone.)
Of course I'll eat their food, and of course I'll listen to the PR flacks. That doesn't mean that I'll write a review based on what flacks tell me.
As a founding member of the Internet Press Guild (www.netpress.org) I subscribe to a canon of ethics that require me to write what I experience with products, not what someone tells me to day. That includes editors -- there has been more than one article I've pulled because an editor disagreed with my findings. IT'S MY NAME. Stephen Satchell Satchell Evaluations
I have the dubious honor of being the first paying customer for Nevada Bell DSL -- now a part of SBC Advanced Internet Services -- in Northern Nevada (the Reno area). My service was installed over a year ago. At the time, I elected to go with "Nevada Bell Internet," a re-brand of PacBell Internet...and an unwanted step-child it was, too.
In the early days, NBI was using bridging mode instead of PPPoE, so it was no problem at all to shift the install from the Windows 98 system I stuck in front of the installer to the Red Hat Linux system that functions as my NAT firewall.
Because of a number of issues documented elsewhere (dslreports.com) I fired NBI and went with another ISP, a then-local company called Pyramid.Net.
One of the reasons I went with Pyramid.Net was the promise from the operator that they would continue to use bridging mode, instead of moving to something like PPPoE. They have kept their promise.
Pyramid.Net is not the only "partner" to SBC to provide briding mode access, which is a true always-on service (as opposed to the necessity of logging in a la PPPoE) with a surprisingly high availability.
Moral of this tale: go with a "partner", not the [A-Za-z]+ Bell Internet company.
The newsgroup comp.dcom.xdsl regularly carries postings from people with horror stories. Note particular those stories told by Bell Atlantic customers...
OK, I took a once-over through the document (I actually looked at the Word one) and was unimpressed. Most of my feelings were expressed by others, so I won't repeat them here. As far as being able to do system-level code, it has a number of problems. (Of course, who in their right minds would code an OS, for example, in C++?)
The big problem I see, though, is that people who are doing telecom protocols are going to find tough sledding in using McLanguage to build packets.
What I want to know is, exactly WHO is the audience for this new, non-portable language?
Just an observation: wasn't the whole idea of the formulation of the GPL to mimic the commercial shrink-wrap license?
That would be the root of the argument made by an Anonymous Coward earlier in this thread, that the collapse of the GPL in its current form would weaken all shrinkwrap agreements.
I would be interested in hearing what the Software and Information Industry Association (formerly the Software Publishers Association) has to say on the issue. (You can look, but when I posted this nothing was there on the subject.) Then there is the Association of Shareware Professionals who also haven't said a word.
Why bring up the ASP? I suspect that if the GPL falls, so will the shareware license agreements, and pretty much for the same reasons: privity. Remember, shareware is meant to be distributed by the buying customer to other third parties.
IANAL
One way to insure privity of subsequent users of the GPL'ed code is to include a reference to the GPL and a further requirement that any modification leave the reference intact within each file of the source code. This would include all header files, make files, configuration files (now you know the real reason that they all allow comments), as well as a LICENSE file.
Many packages already have license terms embedded in the source, but by no means ALL the source.
Because the source is the item being licensed by the GPL, having the license as part of the source at the top of the source pretty well puts any downstream user on notice.
I wonder if Douglas Adams had read the book The Decline and Fall of Practically Everybody by Will Cuppy?
The book consists of a series of essays on well-known figures of history, with the main text giving the (usually) straight dope and the many, many footnotes (a Cuppy trademark) making fun of it all. Underneath the footnote humor was a wonderful set of irreverent observations, some of which struck me as fodder for master thesis topics for historian candidates.
Failure, presented in a funny way.
As I recall, the book was on the USA best-seller list for weeks. I didn't see it until much later (in paperback). If my history classes had been taught in this way, I might have been hooked on history instead of bits.
I would like to point out that the utility companies -- electric, water, and other less interesting -- have looked at what it will take to provide very wideband server. Some have announced the deployment of huge-pipe services.
You can bet that Sprint, AT&T, and so forth will have to pay to use that bandwidth. Indeed, PacBell thought they had bought bandwidth (but the deal fell through) so packets routed through that peering arrangement were dropped on the floor. From Nevada, I was blocked from most sites in Northern California, and was forced to set up a router of my own to divert traffic from PacBell's network to Concentric's network. (Lots of fun, and at 3 AM to boot.)
Nothing stops a company from providing wideband transport and competing with the Big 5.