• no error on transmission failure
• no failure on invalid recipient
• no assurance of delivery to temporarily disconnected recipient

All of which amounts to the result that when you do send a text you have no idea if the number is correct, if the message went through, and in the event the person’s phone is turned off if he’ll ever see it.

Now, I really don’t care if the flaws are in the protocol, the phones or the services we pay for; what I do know is that it all makes for an appalling technology whose reliability imitates Microsoft’s infamous msn messenger where messages constantly go missing without notice. I hear all the time about messages I never saw and apparently when my phone is off for a few days there is zero chance of getting messages sent in that interval.

Compare it to email, which doesn’t have any of these flaws, and it seems incredible that we are actually paying to use this.

And that’s to say nothing of the horrendous user interface for typing messages on a phone to begin with.

This entry belongs in a comprehensive tome I have been writing in my head for a decade, detailing just how much cell phones suck. But the field is so vast that it overwhelms my ability to articulate it.

Ruby is a great language, but one thing it needs is process. And what seems to suffer most from this is documentation.

1. Ruby’s not ready
2. Ruby 1.9.1 released

So I’m researching .NET/Mono for an application I might be doing for Windows. There are two important constraints:

• The application shall not require installation privileges. (Or users in locked down environments might not be able to run it.)
• The application shall be maximally robust with respect to runtime environment. (So that I can leave it behind with the best possible hope that it will work for years.)

The first rules out shipping an install bundle of any sort, and the runtime environment is presumed to be a vanilla Windows install. At most I can hope for a .NET runtime since it comes with XP-SP2 (I think) and certainly Vista and onwards. As for the second, I’ve considered things like py2exe, which bundles code with .dlls for Qt and whatever else the python code actually uses. While this seems to produce a self sufficient bundle (without requiring an install), how do I know if py2exe is going to be around in a few years when I may need to rebuild? And the Qt libs for that matter, they depend on OS-level libs that may change over time, that I have no control over.

So .NET seems to be the best only choice. Now, I obviously want to be able to run it on Mono as well, if for no other reason than to run it myself. So I have to stay clear of .NET-only bits.

That means hello Windows Forms (WPF is out, Mono doesn’t support it). Now, I should say first off the bat that I’m not a gui coder. I don’t like gui, it takes too much work to produce a really good gui, and it’s way more hassle than I like to put up with. Nevertheless, I’ve seen a few of them. And Windows Forms… it’s something else. On the face of it, the .NET library seems to be stocked reasonably, with classes for gui controls (System.Windows.Forms) and for drawing primitives (System.Drawing).

But then you look at some example code and you have to pinch yourself cause it’s so unbelievable. I should preempt here by saying that all the gui toolkits I have seen in recent history handle layouting the same way: with layouts. You create a container that is, say, a grid, and put some widgets in it. The layout takes care of distributing the widgets in the container in a particular way. This takes care of resizing, because the widgets scale to the size of the container (and the containers, in turn, to the size of the gui). Containers can be nested to produce panels and so on.

Far be it for me to say that I like coding gui this way. It’s a huge pain to set all this up. And it doesn’t make resizing work well either, you have to put in a lot of extra effort just for that part. But at least it’s a reasonably clean solution, and it’s how Swing, WxWidgets, and I’m pretty sure Gtk and Qt as well, work.

Not Windows Forms. In Windows Forms you have containers, but there are no layouts. Everything is positioned with coordinates. As in here is a button, put it 5 pixels from the edge of the container; here’s another button, put it in this location I have computed manually based on the first button. This has implications:

• positioning is pixel based,
• dimensioning is absolute – no resizing possible,
• there is no rendering.

As it turns out, the gui form is basically a canvas you can paint on. Widgets and drawing mix freely on the same pane. But remember that Drawing api I mention? It’s pixel based, no Qt or Cairo rendering for shapes or fonts. Neither does .NET have any kind of svg-based rendering that I know of.

The whole thing makes me feel like a time traveler. Remember that Windows Forms isn’t a deprecated library, it’s still actively used (and Mono just recently got done implementing it).

So why bring this up? It’s good to remember sometimes that just because something is hyped a lot doesn’t make it good. Remember, .NET 3 only appeared recently, in 2006. That makes Windows Forms the designated gui toolkit right up to that point. Swing, ugly as it may be to look at (and sluggish as it’s always been) came out with Java 1.2 in 1998. (As a matter of fact, I think even AWT had layout managers in 1995.)

Audio in linux, how to put it into words? How about: oss, alsa, pulseaudio, esound, arts, portaudio, jack, gstreamer, phonon. Did I miss any? Embarrassment of riches? Or just embarrassment?

I will not rehash history any more than to say that between buggy/incomplete drivers for sound cards and the wonderful world of alsa I’ve never been able to understand how the hell audio works beyond getting output and, sporadically, input. I am the quintessential dumb user of linux audio, even though I have tried to figure it out.

But let past be past. Ubuntu 8.10 Intrepid. Pulseaudio ready and everything, since 8.04. Why Ubuntu decided to plug in pulseaudio without setting up any gui controls for it is beyond me. All I know is that occasionally sound output will stop working (I get 2 seconds of output and then it stops) and then “pkill pulse” cures it.

Let’s run through the list.

alsamixer

I’ve learned to use alsamixer to fix low level audio problems. It is reliable in that it gives me all the channels on my sound card, so I always use it to mute/unmute my microphone and to untangle the master/pcm/headphones/front speakers settings caused by mixers that only allow me to control the volume of one channel and apps that output on god knows what channel.

That’s alsamixer on a Ubuntu 8.10 desktop with all updates installed as per today. Here’s the same thing on my laptop.

Same distro, same version, all updates installed. And I have made no conscious choice for this to come about, all I did was install the pulsaudio gui tools. All of a sudden, alsamixer is useless as it only has access to a single “master” channel. It would appear now that pulseaudio is sitting between the sound card and alsa, but does that sound right?

pulseaudio gui

pulseaudio is here, might as well use it, right? Ubuntu ships a bunch of pa* packages that are gui tools for pulseaudio (not installed by default). This one is called pavucontrol. It lets you set volume per audio stream. I love this, I’ve wanted to have it since forever.

But then it comes to output and what do I see?

A single output device. Where is my master, my pcm, all my channels? What’s more bizzarre is that pulseaudio says it’s connecting to alsa while alsamixer says it’s connecting to pulsaudio. Surely that way madness lies?

What’s worse, pavucontrol is a gui app without any kind of systray integration, so much as I would like to use it as an easy-to-reach mixer, I can’t.

kmix

I run kmix in my tray, it lets me set the volume by scrolling the mousewheel over the icon, which is exactly what I want. It’s not a terribly impressive mixer, as it only lets me select one channel to control, whereas what I really would like is to be able to lock several output channels into one, otherwise I’m never really in control. So the best I can do is set the volume to max on master, and tell kmix to show me pcm. That seems to work well enough.

It appears I have two identical channels, but the leftmost is misnamed, that’s actually Master.

Now, let’s see. alsamixer doesn’t show any of these channels, because it delegates to pulseaudio. So kmix connects to… god knows what, but at least I can access these channels.

gnome-volume-control

Gnome’s volume manager is an interesting one. It has a combo box for devices. I’m showing here all the devices related to output and how channels are connected.

The good news is that the channels in the default mixer correspond to those in kmix (sweet sanity!). But then there is that bottom mixer with a channel of the same name as the single output channel in pavucontrol. And yes, they are the same (and the same as the single output in alsamixer).

But this channel appears to be some kind of composite output channel that has no bearing on any of the output channels in the top mixer (or in kmix). (Ie. while it might appear to be a composite pipe that aggregates the flow of all these standard channels, it’s actually a pipe that sits after all of them. If pcm volume is 0, this channel won’t receive any input, and will be mute no matter its volume setting.)

So neither can I effect the settings of master/pcm/etc with this channel nor vice versa. That means if I want to use this single channel as my master volume control, I have to make sure that absolutely no application can mess with the volume for any of the standard master/pcm/etc channels. Good luck with that.

A sane spec

I know this sounds crazy, but what’s it gonna take to get a single server+mixer applet that

• captures every possible audio stream, no matter the audio server/api it’s on,
• prevents applications from messing with master volume controls (eg. mplayer),
• has a single virtual channel controlling all the underlying output channels, so that I can have a single master volume slider,
• has per stream/app volume controls pulseaudio style,
• integrates well into the systray,
• integrates with laptop hotkeys

?

UPDATE: Ubuntu users can now vote on a proposal to unify sound systems on ubuntu brainstorm. Hopefully this idea and the related ones can gain some traction with Canonical to attack the problem.

Here’s my perspective on it. We all have ideas, some good and some bad. Now it’s understandable that people who have invested themselves into a bad idea, especially if they thought it was good, are reluctant to walk away from it. It’s painful to have to realize that. But the flip side is that we have to maintain the myth of Santa Claus because, well, so many kids believe in him that we can’t let them down. Bad ideas deserve to die for the good of everyone.

The first thing a good idea must have is a real problem to solve. OpenID does very well here. The point of OpenID is to solve our common problem of the internet age: many websites, many accounts, many usernames and passwords. This is probably why OpenID still appears to some people as being a good idea.

Here’s how they do it. Instead of keeping track of your accounts on all the sites you’re a member of, just let one site keep all your account records (sound ominous yet? it did to me). Now, whenever you want to login to one of your sites, instead of using your username/password for that site, you use your OpenID login, which looks like this: http://username.myid.net. This url is effectively your OpenID provider, ie. the site you use to keep track of all your accounts. So now the site you’re logging into sends you to your provider, where you login with a username/password belonging to the account on the provider site, and that logs you into the site you were visiting. So in other words, your account on the provider is the gatekeeper to all your accounts. Sounds simple, right?

I remember when I first heard about this idea years ago. The first concern I had was that in order for this to work, I need a provider to keep track of all my accounts. So I asked myself the question: whom do I trust do this for me? The answer came back: myself. I don’t know about you, but the idea of some third party storing all my logins doesn’t make me feel warmy and cuddly. As it happens, the open in OpenID means you can choose any provider you want, including yourself. You just set up some php scritps and voila, you can use http://mysite.com as your provider. So basically, instead of storing your accounts in some “account manager” program on your computer, you do the same thing on your server. This is where the concept of OpenID died for me. I don’t want to have to depend on my own OpenID provider to work in order to use other sites. I don’t want to add a dependency on my ability to login to some other site contingent on the assumption that my own site is available and working properly at all times (which it isn’t, I have a little downtime like everyone else).

If you don’t want the hassle of being your own provider, you can pick a provider from a list. This is not an attractive fallback option, because now your account on the provider is your key to all your other accounts. If I have an account on some site and I forget my credentials, big deal, I only lose that one account. But if I lose my credentials on the provider, I lose everything.

In theory, OpenID tries to improve your overall security. The hassle of keeping track of accounts is known to us all, and we get around the problem by reusing the same (or similar) credentials on a lot of sites. This is obviously bad for security, because if someone gets your password to one site, they can access all your other accounts that use this password. So security people will always recommend that you use distinct credentials for every account. Suppose you do this, and you use OpenID to alleviate record keeping. Now, OpenID actually works against you. Your account on the OpenID provider is the key to everything. With a different password on every site, you’re that much less likely to remember what it was, therefore your account on the provider is proportionally more valuable.

There is a strange irony at play here. Supposedly, the more accounts you manage with OpenID the more useful it is. But on the other hand, the more accounts you manage with it, the more you depend on it, and the more you make it the one gateway to all your online identities for a potential attacker or for abuse by a dishonest or incompetent provider.

Most importantly, however, OpenID’s solution to the login problem isn’t a very clever solution at all. Typing http://username.myid.net is not a big improvement over a username/password form. My browser already gives me the option to login without typing anything.

Those are my reasons why OpenID is a bad idea and should have died years ago. If you want more, Stefan Brands has an exhaustive laundry list of problems with OpenID.