What is the bandwidth of one voice talking?

A side question to the previous post: About how much information does a voice convey per unit time? Let's neglect tone of voice here; it's clearly important in real speech, but my guess is that if you could quantify it, it would come out to not very many bits (Happy? yes/no. Angry? yes/no. Sarcastic? yes/no. etc., each changing fairly seldom). It's also not something that computers are terribly good at picking up, so it's not relevant to the particular case of speech recognition.

At an upper limit, how fast can people talk? Appearances can be deceiving here. That auctioneer rattling on a mile a minute is really just continually refreshing two 2- or 3-digit numbers (possibly with some zeros attached) that change every few seconds. That person zipping along in a foreign language isn't really talking significantly faster or slower than you would, but it sounds like a lot since you don't understand it. And of course, some people can say more with a word than others can say with a paragraph.

The record for speaking English appears to be around 10 words per second (yikes!). Mind, this is most likely someone spewing out a prepared spiel that they've practiced over and over again. Assuming about 10 bits per English word (estimates vary a bit), that's about 100 bits per second. My guess is that most of us, particularly those of us actually coming up with the words as we go along, would do well to hit half that. On the other hand, most of us type considerably more slowly than that.

So let's figure 50 bits/second for running speech, for example, if you're dictating a letter. What if you're just barking out commands from a set list? Interestingly, bandwidth drops considerably. For example, if it takes half a second to bark out one of 16 commands, that's 8 bits/second. Not exactly broadband.

Some day you will be able to talk to your computer

Actually, you can do that now. The trick is getting it to listen.

I heard someone on the radio talking about how before too long, keyboards were going to be practically obsolete. Typing, they said, is just one way of communicating with a computer. Why should you type in, say, a search phrase when you could just say "Where's a good Thai restaurant in the area?" and have the computer google it up?

The "just another way of communicating" angle rang a bell, and now I remember which bell. It's the same reason text is supposed to be dying. I've already argued that, um, there must be something amiss with that position, but killing typing is not the same as killing text itself. One could imagine a world in which we still read text, in all its visually-tuned, random-access glory, but create it using voice recognition and a mouse (or a pen, or touchscreen, since mice are about to be obsolete as well, but let's stick to one UI device at a time).

We shall see. Speech recognition (technically, voice recognition means figuring out who is speaking as opposed to what they're saying) has been around for a while now, getting steadily better. There now appear to be dictation systems that can capture most people's normal, continuous speech with high accuracy. This is important, because having to speak ... slowly ... and ... distinctly ... for ... long ... periods ... of ... time or constantly correct monsieur's misheard words rapidly negates any advantage in ease-of-use.

Nonetheless, I'm not sure speech is going to take over as completely as one might think. Why do people send text with cell phones? One would be hard-pressed to imagine a more tortuous way of producing text than to thumb it in on a tiny numeric pad, especially before word recognition, but people did, and do, even when they could call, or leave a voice mail. Or for that matter, why do people IRC while on the phone?

Conversely, how often do you get an email with a voice attachment? I doubt bandwidth or storage are significant problems for that any more. Speech requires around 3Khz of bandwidth and compresses quite a bit better than, say, classical music.

Personally I would prefer not to talk to my computer much of the time, either because the environment is noisy (playing havoc with accuracy), or because it's quiet (and I don't want to disturb anyone), or because there's someone else in the room I might like to talk to without confusing the UI. Occasionally I might even want to mutter some choice words at it without them showing up in the latest blog post for all the world to see.

In short, speech recognition is useful now (particularly if typing is difficult or impossible for a person) and will continue to become more useful as the technology continues to improve, but I don't see it taking over the world.

Postscript: Long ago I decided I was going to get rich by selling a computer that would run faster if you yelled at it. I could have done it, too. Just hook up a volume meter to the system clock. When nothing's coming in, the system runs at, say, half speed. As the volume increases, the clock comes back up to normal. Of course, you'd have to get people used to a computer that runs artificially slowly. But that's a solved problem ...

AJAX and samsara

Of the many aspects of the software biz that never ceases to amaze me is how many things I've learned over the years that Ivan Sutherland already knew before 1970. For example, from esr's Jargon File, aka The Hacker's Dictionary (v. 4.4.7):

wheel of reincarnation

[coined in a paper by T.H. Myer and I.E. Sutherland On the Design of Display Processors, Comm. ACM, Vol. 11, no. 6, June 1968)] Term used to refer to a well-known effect whereby function in a computing system family is migrated out to special-purpose peripheral hardware for speed, then the peripheral evolves toward more computing power as it does its job, then somebody notices that it is inefficient to support two asymmetrical processors in the architecture and folds the function back into the main CPU, at which point the cycle begins again.

Several iterations of this cycle have been observed in graphics-processor design, and at least one or two in communications and floating-point processors. Also known as the Wheel of Life, the Wheel of Samsara, and other variations of the basic Hindu/Buddhist theological idea.

(My understanding is that the graphics world is in the process of turning the wheel another notch with the GPGPU)

To this list we can the thin client/fat client oscillation, and at the moment the pendulum is swinging toward thicker clients. Thus AJAX.

Clearly there isn't one inherently correct solution to these sorts of "where do I put the processing power" questions. The answer at any given moment depends on economics: How much does processing power cost (and how much can you gain by concentrating it in powerful servers)? How much does bandwidth cost? How much do the various models cost to develop, test, deploy and administer?

A related question: How much development effort goes into new products and solutions, and how much goes into adapting existing products and solutions to the pendulum's latest swing?

Sorting out AJAX

I've tagged a few posts here "Web 2.0", but I haven't said anything here (until just recently) about AJAX. So here's a quick take.

AJAX normally stands for three things:

• A is for asynchronous, meaning that your browser doesn't (always) have to wait for the server it's talking to to get back to it.
• J is for Javascript (or JScript, or more technically ECMAScript), which is one way for your browser to run custom code on its own while it's not waiting for the server.
• X is for XML, which is XML.

For my money, these are listed pretty much in order of their importance to the picture. If you have some means of decoupling the browser from the "send request - wait for response - display response" routine, then it matters less exactly how you're telling the browser, say, how to display a list of choices that all begin with the letters you typed. It matters even less how the names behind that list happened to look on the wire when the server sent them to the GUI code the browser is running.

In theory, the browser could use any language for its scripts. ECMAscript is the choice in practice because it's close to languages like Java and C# that lots of people know [... ehhh, depends on what you mean by "close".  If you mean syntactically, sure, but the computing model underneath is notoriously idiosyncratic --D.H. Dec 2018], and more importantly because the major browsers support it.

XML is even more a matter of choice. If you're building a web page, you can define your own format if you really really want to. Or you could use JSON, or anything else you can find a library for. Not to say that there aren't arguments for using XML, just that "it's the only game in town" isn't one of them.

But you can't do any of this fun stuff without a way for the browser to take on some of the processing, and particular to be able to do that processing without waiting for a server response. The A for "asynchronous" is the essential "what" here. The J and the X are the vital but to at least some extent interchangeable "how".

My vote for most annoying new web site feature of 2007 ...

... goes to those double-underlined links that pop an ad up in your face when you try to chase them. I can understand the desire to get some kind of revenue out of providing useful information, but this stuff makes me think of Digicrime (no double underlines on that one, but please read their disclaimer before you go playing around there).

Economic copy protection

Suppose I've created something really cool, say a screensaver that's so entrancing that when you see it on my screen, you've got to have it. I agree to give you, and only you, the binary for it, for a hefty sum. Bear with me -- it's a thought experiment.

You've got the binary. I've made no effort to copy protect it. You can copy it as much as you want and give it away to all your friends if you want. Will you?

My guess is no. If you've paid a bunch to have my screensaver on your screen and your screen only, why would you give it away? Will I copy it and give it to someone else? Not if I want to do business with you again.

In effect, the work is copy-protected, but by economic, not technical means.

Now suppose you grow tired of my creation. You could just give it away then, but why not try to get something out of it? Say, sell it to your six friends that have been drooling over it, with each paying 20% of the original price you paid me. They get the cool screensaver at a heavily discounted price (to make up for their not having had it hot off the press), and you get a cool 20% profit. Plus the use of the cool screensaver in the meantime.

But If I'd known you were going to do that, I would have been better off just selling to you six friends to begin with, and maybe to you as well if you could tolerate not being the only one with the new work.

With more customers I can charge less per customer, but by charging less I will also pick up more customers who don't see any need to refrain from copying the work and giving it away. If you pay, say, $4 for something and get as much enjoyment out of it as you would from a fancy cup of coffee, your investment at that point is zero. So why not give it away (absent any technical or legal barrier)?

This code comes with ABSOLUTELY NO WARRANTY etc., etc.

Kinda lame, I know, but I didn't have time to make it really lame.


#include <stdio.h>
main(){char *s="#tcg[\"ygP\"{rrcJ23";while(*s++);s--;int _=0,j=9,c=42;
while(*s!='#'){putchar(_++<2||_>298?*--s-2:_&16?8:_&15?46:j--+48);
if(!(_%32-10)){fflush(stdout);sleep(1);}}putchar(10);}


Radiohead: Just what is going on here?

A few months ago Radiohead put out its latest album, In Rainbows, in two formats. You could get a "discbox" with a vinyl pressing, bonus CD, album art, etc. for a fixed price, or you could just download the tracks as .mp3 files and throw whatever you wanted (or nothing) in the tip jar.

So what happened? Who paid what? Do we have a whole new paradigm for music sales? An interesting one-off experiment? An out-and-out boondoggle? All or none of the above?

It's hard to see In Rainbows as a whole new paradigm, if only because there are so many special circumstances. Radiohead is an established band with a loyal following and a formidable reputation. The band happened to be between record contracts for this album. The downloadable version was a companion to a more traditional offering. And Radiohead is Radiohead. What works for them might not work for anyone else.

In fact, it may not even have worked for them. Certainly the band saw the online release as a one-off. They are currently in negotiations with both record labels and iTunes, and the download offer has been discontinued (effective New Year's Eve).

Beyond that, the picture gets very muddy very quickly. One report, by Gigwise, claims downloads of at least 1.2 million copies of the album. How much did people pay? Those who know aren't talking, but one survey indicates an average of 4 pounds (about $8), with 1/3 of downloaders paying nothing. Another, hotly disputed by the band, suggests that 62% paid nothing and the average price across all downloads was $2.26.

So basically, we don't know how many copies were downloaded, how much people paid for them, whether the price paid changed over time, why there's a discrepancy between the two surveys, or much of anything else. Except that the band most likely pulled in millions of dollars for the downloads, some further amount for the discboxes, and expects further income from traditional distribution. That's not even counting the T-shirt sales. Not bad for a bunch of guys from Oxfordshire.

If the tip-jar/download approach is not obviously the future of music distribution, but it's not a massive flop either, what is it, and why is the band discontinuing it? Is it the tip of the iceberg, or an evolutionary dead end like the million dollar homepage?

My guess, and it's only a guess, is that the tip-jar model is not going to dominate, though it might not disappear entirely. Rapper Saul Williams is currently spinning a variation on this with a low-bandwidth version of his latest release. The hi-fi version is available for a $5 donation.

Why is the band discontinuing the offer? My recollection from the original page is that it was never promised indefinitely in the first place. Most likely the band has gotten the good out of it. I would expect that people who care enough to pay also care enough to download early (which might explain some of the discrepancy between the two surveys). The band also seems not to have burned its bridges with traditional distribution channels, and continuing the "It's up to you" offer would only muddy the waters there.

100 and (I hope) counting

According to the "Blog archive" heading, this will be my 100th post to this blog. Stephen Jay Gould took a similar opportunity to tell us, finally, about his field work on Bahamian land snails. I'm more with Eubie Blake, who celebrated a 100th birthday and who said "If I'd known I was going to live this long, I would have taken better care of myself."

I won't be writing about my equivalent of Bahamian land snails -- I wish I had something so interesting to draw on -- but on something more apropos of Eubie Blake. Blake, as it turns out, really only lived to be 96 (most of us should be so lucky), and that seems as good a point as any to pick up a thread that's been running through this blog more or less from the beginning: imperfection.

When electronic computers first entered the popular consciousness sometime after World War II, their defining property was perfection. If the hero needed the answer to an intractable problem, the computer was always there, ticking away impassively. On the darker side, the flawless, emotionless and relentless android, aware of its own perfection and our human inferiority, was a stock villain.

The computer was the ultimate in modernism. Its rise coincides, perhaps not coincidentally, with the shift from modernism to whatever we're in now, variously postmodernism or late modernism, depending on whether you want to emphasize change (how modern) or continuity.

The notion of the all-knowing perfect computer dissolves rapidly on contact with actual computers. One of my early experiences in computing was meeting my dad's friend Herb Harris, who ran a computing facility in the building . I vaguely recall watching cards being punched and read, but I definitely recall suggesting that you could use a computer to store everything in the encyclopedia (and therefore, all of human knowledge).

Herb loaned me a book I still have, somewhere, on programming the IBM 360. He also gently prodded me to consider what putting an encyclopedia in a computer would mean, particularly the question of how you would find the information once you got it there. To give you an idea of the hardware of the time, the book contained a recipe for doing decimal multiplication by use of a multiplication table you could read in from external storage. I concluded that the problem was harder than it looked, but still ought to be at least partially solvable, with somewhat better hardware. Maybe I'd get back to it later ...

Now we have vast collections of textual material available via computer, and we have at least one usable way of finding the information that's there. We even have encyclopedias on line. All this information, its storage and its retrieval deal intimately in imperfection. Some examples:

• Dangling links are explicitly allowed in the web. This is not an accident but a basic tenet of web architecture. Allowing links to point to nothing means that you don't have to build a whole site at once, or even know that it will ever get built. Among other things, dangling links are a key part of the wiki editing experience (not as much fun if you just want the information, though).
• The underlying protocols the web is built on assume that messages routinely get dropped or duplicated in transit (TCP), that the information you are looking for may in fact be somewhere else (HTTP), or that the server you're ultimately trying to reach may be down (HTTP again).
• Documents are given logical addresses, not physical addresses, on the assumption that information may be physically moved, without notice, at any time. For that matter, computers themselves also generally go by logical names. There is no one perfect physical realization of the web.
• The web inherently doesn't assume that any given document is the last word on a given subject. Search engines generally give you some idea of how well-connected a page is, but this can change over time and in any case it's only a hint. Anyone can comment on a page and incorporate that page by reference.
• You can't take anything on the web at face value, or at least you shouldn't invest too much faith in a page without considering where it came from (which you don't always know) and how well it jibes with other sources of information. This sort of on-the-fly evaluation quickly becomes a reflex.
• From a purely graphical point of view, there is no definitive format for a given web page. If you try to lock everything down to the last pixel it will generally look bad on displays you didn't have in mind. If you don't, it's up to the browser at the other end to decide what it looks like, and with CSS and other tools, the viewer can have almost unlimited leeway. Nothing is perfect for everyone, so we try to get close and allow for tweaks after the fact.
• A key part of running a successful web site is managing details like backup, maintaining uptime in the face of hardware failures and (one hopes) dealing gracefully with large numbers of people pushing the limits of your bandwidth. This is hard enough that you generally want to farm it out.

There are many more examples, and probably much better ones as well. The point here is that even when it looks like the system is working just fine, imperfection is everywhere. The web tolerates this rather than trying to stamp out every last flaw, and in some fundamental ways even builds on imperfection. The result is far more powerful and useful than a computer that never loses at chess or never makes an arithmetical error.


Postscript: Herb Harris is no longer with us, but the University of Kansas student computing lab bears his name [... or it did for a while.  Somewhere around 2010 the trail seems to go cold.  Now that everyone has a phone or laptop and storage is in the cloud, there's no longer such a need to go to a place in order to compute.  The building is still there, but it now houses "Information Technology".  Sic transit ...  -- D.H. Dec 2018]

80% of the solution in a fraction of the time

As can happen, I set out to write this piece once already, only to end up with a slightly different one. Here's another take, bringing Wikipedia into the picture.

First, let me say I like Wikipedia. A quick scan will show I refer to it all the time. I see it as a default starting point for information on a particular topic (as opposed to a narrowly-focused search for a given document or type of document). I don't see it as definitive, but I don't think that's really its job.

Wikipedia would seem a perfect test case for Eric S. Raymond's formulation of Linus's Law ("Given enough eyeballs, all bugs are shallow). But -- as Wikipedia's page on Raymond dutifully reports -- Raymond himself has said, well, here's how it came out in a New Yorker article:

Even Eric Raymond, the open-source pioneer whose work inspired Wales, argues that “ ‘disaster’ is not too strong a word” for Wikipedia. In his view, the site is “infested with moonbats.” (Think hobgoblins of little minds, varsity division.) He has found his corrections to entries on science fiction dismantled by users who evidently felt that he was trespassing on their terrain. “The more you look at what some of the Wikipedia contributors have done, the better Britannica looks,” Raymond said. He believes that the open-source model is simply inapplicable to an encyclopedia. For software, there is an objective standard: either it works or it doesn’t. There is no such test for truth.

Let's start right there. Software doesn't simply either work or not. You can't even put it on some sort of linear, objective "goodness" scale. Even in cases where you'd think software is cut and dried, it isn't. Did you test that sort routine with all N! combinations of N elements? Of course you didn't. Did you rigorously prove its correctness? How do you know your correctness proof is correct? Don't laugh: Mathematicians routinely find holes in each other's proofs, in some cases even after publication.

But most software is nowhere near this regime. Often we don't even know exactly what we're trying to write when we set out to write it (thus much of the emphasis on "agile" development techniques). In the case of something like a game, or even a website design, most of what we're after is a subjectively good experience, not something objectively testable (though ironically games seem to put a bigger premium on basic correctness, since bugs spoil the illusion).

It's not even completely clear when software doesn't work. If a piece of code is supposed to do X and Y, but in fact does Y and Z, does it work? It does if I need it to do Y or Z. What if it hangs when you try to do X, but there's an easy work-around? What if it hangs at random 10% of the time when you try to do X, but that's tolerable and nothing else does X at all? What if it does X if a coin flip comes up heads, but might not if it doesn't? I'm not making that one up. See this Wikipedia article (of course) for more info. What if it's an operating system and it just plain hangs some of the time? Not that that would ever happen.

All of this to say that I doubt that software and encyclopedia entries make such different demands on their development process. And as a corollary, I think the results are about the same. Namely, there are excellent results in some cases, reasonable but not excellent results in many cases, and occasional out-and-out garbage.

Here's what I think goes on, roughly, in both cases:

• Someone comes up with an idea. That person may be an expert in the field, or may just have what looks like a neat idea.
• The original person produces a first draft, or perhaps just a "stub", or an "enhancement request".
• If no one with the expertise to take it further is persuaded to do so, it stays right there indefinitely, or may even be purged from the system (perhaps to re-appear later).
• If the idea has legs, one or more people take it up and make improvements.
• Typically, one of three stable states is reached:
• It's perfect. Nothing more than minor cosmetic changes can be added. New ideas along the same lines typically become their own projects.
• It's good enough for everyone currently involved. That may not be particularly good, but no one can be persuaded to go further. This may be the case right out of the gate, or after several rounds of fixes by a single originator.
• It's not good enough, but there is no agreement on how to take it further. Work may grind to a halt as competing fixes go in and come out, or the project may split into two similar projects, with better or worse sharing of common material and effort.

Thinking it over, this process is not unique to open source. The magic of the open approach is that the bigger the pool of participants, the bigger the chance that an idea with legs will get supporters and get fleshed out, and the faster it will get to a stable state. In our imperfect world, that stable state is generally short of perfection. Put the two together and you have 80% of the solution in a fraction of the time.

That said, there are some differences between prose and software. I've argued above that software isn't hard and fast. It's soft, in other words. But prose is even softer. As a result, there is greater potential for disagreement on where to go, and in case of disagreement, there looks to be a better chance of thrashing back and forth with competing fixes, as opposed to moving forward but with separate (and to some extent redundant) solutions.

Wikipedia does seem to attract more vandals, but this is not necessarily because it's not software. It may also be because it openly invites frequent edits from a very large pool and changes are moderated after the fact. Open software projects, particularly critical pieces like kernels and basic tools, tend to require changes to pass by a small group of gatekeepers before being checked in. Conversely, some wikis are moderated.

As usual, this is all just my rough "figuring it out as I go along" guess, not anything with actual numbers behind it, but that's my story and I'm sticking to it for now.

Eyeballs and shallow bugs

Eric S. Raymond has asserted that "given enough eyeballs, all bugs are shallow", a principle he calls Linus's law after Linus Torvalds (my fingers want to type "Linux Torvalds").

How many eyeballs are enough? How many eyeballs are available? What does it take to get a "shallow" bug fixed, checked in and tested? What's a bug, anyway? A few meditations:

How many eyeballs are enough? Suppose an excellent kernel hacker has a 90% chance of nailing a given bug. What are the chances that two excellent kernel hackers can nail the bug? Well, it's not 180%. It will range from 90% (if the second doesn't know anything new about the particular problem) to 100% (if the second knows everything the first one doesn't).

If the two are completely independent sources of information there's a 99% chance one or the other will nail it. But what are the odds two people got to be excellent kernel hackers by completely independent routes? Now, what are the odds that a bunch excellent kernel hackers, quite a few more reasonable kernel hackers and a horde of non-specialists could nail the bug? Pretty good, I'd say, but not 100%.

How many are there? I've been doing software for a while now. I've built a few Linux kernels (roughly the equivalent of changing a tire on a car), and I've looked at small portions of the source (roughly the equivalent of opening the hood, pointing and grunting). If some subtle race condition should creep into the next version of the kernel, the odds that I could contribute something useful to the conversation are approximately zero (the automotive equivalent might be, say, being able to help fix a problem in a Formula One engine design).

The most qualified people in such a situation are the small and dedicated core of kernel maintainers and whoever put in the changes that turned up the problem. These may well be the same people. I know a fair bit about software in general, and even a bit about race conditions in general, but I know essentially nothing about the details of the kernel, the design decisions behind particular parts, the hidden pitfalls and so forth.

This being open source, much of that information is available, directly or indirectly. The limiting factor is the ability to absorb all of the above. This takes not only skill but time and dedication. The natural consequence is that, for at least some bugs, there just aren't enough eyeballs available to make them "shallow". Instead, someone will have to expend considerable brain sweat figuring out what happened.

[Another not-infrequent case: Lots of people see a bug, but no one can quite nail down what's causing it, much less suggest a fix. Filing good bug reports takes practice, just like writing good code does. Eliminating all the variables in a typical desktop environment takes time, even for someone with lots of practice. As a result, the people who could fix the bug don't have enough information to go on and probably have bigger fish to fry.]

What does it take to get a shallow bug fixed and tested? Suppose that the broken code in question (kernel or otherwise) has passed by enough eyeballs that someone has said "Hey, that's easy, you just need to ..." That person puts in a fix. Are we done? No. At a minimum, someone needs to test the fix, preferably someone other than the fixer. Someone should also look over the code change and make sure it fits in well with the existing code. And so forth. Open source doesn't remove the need for good software hygiene. If anything, it increases it.

What's a bug, anyway? Suppose not just one person steps up with a fix to some bug. Suppose two or three people do. Unfortunately, they don't exactly agree on the fix. Maybe one wants to patch around the problem, one has a small re-write that may also fix some other problems, and another thinks the application wouldn't have such bugs if it were structured differently. Someone else might even argue that nothing needs to be fixed at all.

Expediency will tend to favor the patch, and expediency is often right. The small re-write has a chance if the proponent can convince enough people that it's a good thing. The re-structured system will probably need to be a whole new project, potentially splitting up the pool of qualified eyeballs.


So does this mean that open source is a crock? Not at all. Most of the problems I've pointed out here aren't open source things. They're software things. Open source offers a number of potential advantages in dealing with them. One I think may be overlooked is that writing a system so that anyone anywhere can check it out and build it, and that several people can work on simultaneously and largely independently, enforces a certain discipline that's useful anyway. If your code's a mess or no one else can build it and run it, you're not going to get as many collaborators.

On the other hand, open source isn't a magical solution to all of life's problems, and there are arguably cases where you just need someone to say "Today we work on X," or "We will not do Y." Strictly speaking, that kind of control is a separate question from whether the source is freely available, but Linus's law assumes that eyeballs are not being commanded to look elsewhere.

So is Linus's law a crock? Not at all. It captures a useful principle. But like most snappy aphorisms, it only captures an ideal in a world that's considerably messier and more intricate.

[A few years later, a couple of striking examples turned up, in the form of Heartbleed and Shellshock -- D.H. Dec 2018]