EQL Data in Connecticut

In Farmington, CT, in fact, the town my cat was named after. Oh yes. That's how much we love that place.

Lukasz, Ashok, and Matt will be presenting EQL Data at the Connecticut Access User Group tomorrow (well, by the time you read this, today) at around 5:30pm, at the Microsoft campus in Farmington. If you live in Connecticut, or anywhere else for that matter, you should come check it out! Follow the link for directions and information.

::li,eql

Note to the beloved fans subscribing to my Youtube feed

I don't have a Youtube feed.

I don't post Youtube videos.

I can't find myself on Youtube.

I don't even like Youtube.

And yet I'm getting notifications about it.

So whatever it is you're subscribing to... um, no need. Honest.

Update 2009/12/21: drheld points out that I have, in fact, posted one lousy video to Youtube in the past. I guess this is what I get for creating an account at a random website on the Internet. And yes, that is our dog. We're training her to generate electricity when the Day of Darkness comes.

The disappointingly ongoing success of WvDial

For those who don't know, I'm one of the original two authors of WvDial (Oh yes, that's a real Wikipedia link!)... back in 1998. WvDial and its spinoff C++ library, WvStreams (notably not a Wikipedia link), were the absolute first code written as part of Weaver, our startup's commercial product, which became Nitix (Wikipedia again, but article is outdated) and later Lotus Foundations (Wikipedia "stub" article).

The Wikipedia articles make a pretty good proxy for the comparative success of those programs. Another silly statistic I like is Twitter search (Lotus Foundations seems most popular in Japan at the moment).

Yes, yes, so WvDial remains popular. Yay us, right?

See, that's the funny thing. First of all, wvdial maintenance has been almost zero (not quite zero¹) for most of the last ten years. WvDial has no GUI; it's purely a command-line tool. WvDial is a modem dialer and nobody uses modems anymore. WvDial is written in C++, which is generally unpopular for small tools and makes it ABI-unstable and bigger than you'd like. WvDial has no unit tests and so everyone is (rightly) afraid to change its rotting guts. And perhaps most oddly of all, none of the problems WvDial originally set out to solve are problems today.

This story is not a story of WvDial's awesomeness. It's a story of the open source world's pure unadulterated fabulous nonstop 12-year marathon of suck.

I tried Twitter a while back and I'm pretty much over it, but I do still subscribe to some Twitter search RSS feeds just in case anything interesting happens (it never does). Every single day, several people recommend wvdial to their friends. With comments like "wvdial always works, let me help you set it up." In multiple languages.

Speaking of suck, that Twitter search is how I learned that Ubuntu's most recent release(s?) have dropped wvdial from the CD in favour of NetworkManager. You can still download wvdial from the Ubuntu repo, except... whoops. You can't get online without wvdial. Because speaking of suck, NetworkManager apparently does. (I've never tried it; I haven't used a modem in years.) So we have people who can't get online, downloading the .deb files on another computer and moving them via sneakernet over to their laptop. And so on. People can't live without the thing. I would say they love it, but I still hope that isn't it.

Why WvDial was created

We originally created wvdial back in the late 1990's because setting up pppd 'chat' scripts was too annoying. At the time, a lot of dialup Internet providers required you to answer some menu items, log in, etc before you could start an actual PPP session, and every ISP did it differently... so everyone needed a different chat script. It was all gross.

The point of WvDial is that it would read the stupid inconsistent menus and prompts for you and answer them. For the first few versions, it failed almost every time. But we got lots of feedback from lots of people all over the Internet, and we fixed it. Eventually, it got to the point where basically nobody wrote to us anymore asking why wvdial didn't work with their ISP, even though thousands and thousands of people were downloading wvdial every month. (And that's just from us; we didn't have any stats on who installed it from a real Linux distro.)

But here's the thing. Windows 95 and later have a built-in dial-up PPP feature that doesn't even support anything like chat scripts. All they do is dial up and start PPP, and if your ISP can't handle it, well, that's too bad. Oh, there were ways of working around it, but they were gross, and it didn't take long before most ISPs abandoned their menu structures and just did things the easy way. In WvDial, we called the Windows 95 behaviour "stupid mode" since it was the opposite of wvdial's evolved, intelligent conversation style.

Unsurprisingly, some combination of Worse is Better and "everybody runs Windows" conspired to make wvdial's cutesy menu-guessing features completely obsolete. WvDial is, therefore, completely obsolete. Or so you'd think.

People keep using WvDial because everything else is worse

Why do people keep using WvDial? Well, it's hard to tell from a bunch of foreign-language 140-character Twitter posts. But I've observed the following: a) it's not for modems, it's for coupling to data networks via your cell phone and bluetooth that emulates a modem; and b) just things like detecting the right serial port, baud rate, and init strings, and redialing when you get disconnected,² are apparently still big problems.

This all makes me extremely sad. First of all, pretending your advanced cell phone network is a modem, and thus bringing up questions like "should I use touch tone or pulse dialing?" and "do you think 19200 bps is fast enough?" and "what happens if I get a busy signal?" is a joke. Secondly, the fact that someone couldn't fudge up a bluetooth-cellphone interface for Linux that's more reliable than wvdial, even though wvdial was never designed for this use case at all, just really scares me. I mean, yes, I realized at the time that nobody had ever designed a tool like WvDial on any OS... but surely all the individual parts had been done before? You know, modem detection? Max baud rate detection? Init string detection? And now, more than 10 years later, surely someone has put the still-necessary parts together into a more sensible package? You know, maybe one with a GUI?

Nope.

I can't quite figure out what people like about wvdial so much; why it's the fallback that people still recommend to all their friends when Ubuntu/Gnome's default (GUI, at least, thank God) dialer can't take the pressure. I suspect it's just the fact that wvdialconf tries all your serial ports one by one to guess which one is right, rather than making you do it for yourself.

Perhaps I'll never know.

Happy birthday, WvDial.

(See also: other things that are still not dead.)

Footnotes

¹ I haven't been involved in wvdial maintenance for quite a long time. Thanks to Patrick Patterson, Simon Law, William Lachance, and possibly others (Jim Morrison?) for keeping up with the maintenance over the years.

² Okay, I admit it. WvDial's redialing support is pretty frickin' awesome. If you think about it, it's actually impossible to implement a redial backoff timer correctly using chat scripts. Do I don't think anybody else has even tried.

::eql

Advice to people implementing dynamic dns with easydns.com

Forget about using one of the (many) totally idiotic dyndns clients for Linux. The correct solution is to just call curl from a cron job.

See the description of the easydns.com "protocol". Where by "protocol" we mean a single HTTP GET request.

Note that if you use myip=1.1.1.1 (why not 0.0.0.0?) the server will figure out your IP automatically, which is basically always what you want. Having your (aforementioned idiotic) dyndns client try to guess it for you, when it's almost always behind a NAT router, is totally useless.

I hate computers.

"No Waiting Room" and Queuing Theory

I just read Nat Friedman's post, No Waiting Room, about his experiences in a hospital in Germany vs. one in Boston:

I hadn't been asked to sit in a waiting room for 8 hours like the time I had a concussion in Boston. A few hours later, after my abdominal ultrasound was clear, I poked around the hallway near the main entrance just to confirm what I'd been wondering about. There was no waiting room.

He then goes on to relate this experience to health insurance models in the U.S. vs. Germany, how people respond to them, the number of ER vs. scheduled visits, and so on.

Now, there are surely lots of things to say about the difference between U.S. and German (and Canadian, for that matter) health insurance systems. But I don't think this actually provides a data point either way.

In any system, long-but-not-growing queues are a sign of a very specific kind of failure. People like to oversimplify and assume that a long queue means there aren't enough doctors (for example), but that's not right; if there are more people arriving at the hospital than are being treated, the queue would keep growing. But as far as I know, the queue at the hospital in Boston wasn't ever-growing,¹ it was just really really long. That's a totally different condition. An ever-growing queue is a bandwidth problem; a long-but-constant queue is a latency problem.²

Somewhere in this system is an ineffective queue. What's the optimal route through the hospital queue, and how many people follow non-optimal routes? Does the optimal route involve filling out paperwork for two hours? If so, then your minimum stay is two hours. Does a typical route involve three layers of nurses pre-checking you so they can put you into the right doctor's queue? Each of those layers adds a delay (and probably another delay as you wait your turn for the following stage). Is the traffic bursty, ie. do more people arrive at certain times of day, so that you get an 8-hour queue built up at rush hour, and it empties out by 4am, so the "average bandwidth" is sane but the peak bandwidth is crazy? (Surely people don't get sick only during certain hours, so why would it happen?)

Interestingly, this sort of problem is almost always solvable without spending a lot of money. Upgrading bandwidth requires money; improving latency only requires cleverness. It's a variant of Just in Time manufacturing, where instead of "excess inventory" you have "patients in the waiting room." Companies that do JIT - German manufacturers come to mind - produce efficiency without spending more money.

I'm not an expert in hospitals; not in the slightest. In fact, I live in Canada, so I can't provide useful input on the U.S. healthcare system or the German one, having never experienced either.

But I know a law of the universe when I see one.

Footnote

¹ Why I think the queues aren't overflowing: because if they did, you'd be turning away customers. You might complain about the U.S. health care system being run by profit-seeking corporations and individuals, and I'm sure that has its problems. But if there's one thing profit-seeking entities never want to do, it's turn away paying customers. If the problem were insufficient doctors, for example, you'd be much more likely to see it in socialized systems like Canada's, where doctors' salaries are capped and there's no supply-and-demand effect.

² I wrote about BitTorrent and transmit queues a while ago, and that's another example of the same phenomenon. No matter how fast your network link is, BitTorrent can destroy your performance if you don't speed-limit it; if you do speed limit your BitTorrent, say to 90% of your max bandwidth, whatever your max bandwidth might be, then your latency won't suffer at all. That's the magic of queuing theory. It matters for hospitals just like it matters for networks and highways.