Sirius TTR1 Sucks

All I wanted was to wake up to Howard Stern again. Alas, it was not to be. Sirius sucks. This TTR1 radio sucks. The combination is a whole new level of suck. This will be a rant in two parts.

Part 1: The hardware sucks

The TTR1 is apparently made by Audiovox, although this is not made apparent by the Sirius people. Probably because Audiovox is not exactly the first name in quality electronics.

You cannot operate this thing with one hand. It is not heavy enough to stay in place while you push the buttons on the front of it, so it slowly inches away from you as you attempt to use it, unless you hold it in place.

But really, my biggest complaint is that the power button does not work. Normally I might assume this was just a defective unit, and perhaps it is, but allow me to further explain. The power button actually does work with something like a 1% success rate. About 1 out of every 100 presses will actually affect the machine. These successes are not uniformly distributed. Indeed, the button may work with very good success for a time, and then become utterly useless for an even longer time. This is rather irritating.

Part 2: The service sucks

I took the reliability of terrestrial radio entirely for granted. It’s always there, even if the content is utter crap. Not so with Sirius, especially this internet-radio flavor.

Often, instead of being awoken by Howard as expected, I am awakened by the buzzer alarm. This is the failsafe, the fallback, when the TTR1 cannot successfully acquire the Sirius radio stream. What? There’s a backup plan?

(If I take a deep breath and really think about it, I am sort of amazed that the Audiovox people had to foresight to include this feature. It would have been more consistent with their craptastic design just to allow me to oversleep indefinintely. But I digress…)

The problem with Internet radio is reliability. Mark my words, if you could see Sirius’s traffic stats over time, they would have these giant network spikes every hour on the hour in the morning. They apparently do not have enough network resources to service that peak demand.

It is times like this when I really wish Apple could just make every-damn-thing.

Who Will See What I Type Here?

When I email someone, I know exactly who can read it: the recipient. Same for instant messages. This here blog, now that you mention it, can be seen by anyone with a browser.

I know these things, and it affects what I say.

Twitter? Facebook? Google Buzz? Utter mysteries to me. Just when I think I’ve figured it out, they change all the rules.

I am afraid. I don’t want to share that hilarious text-from-last-night with my Mom.

The internet pundits talk a lot about “privacy controls” these days. That’s fancy-talk. My problem is not nearly so complicated as to require a “control.” Just tell me: who will see what I type here?

Recursive Satisfaction

Gruber writes about a recent clang milestone.

“Recursive satisfaction.” I love that description.

I would add that any program which takes, as its input, another program of the same type, has this potential. Simulators can simulate themselves. Program instrumentation or analysis tools — ditto. I’m fairly certain I’ve even debugged a debugger with itself once.

But, yeah, it’s cool.

Incidentally, if you don’t read Daring Fireball — you’re the only one left. Start now.

The Belly Ball

Quick plug for the Belly Ball, the brainchild of my friend (and fellow crossfitter) Beth Walsh. The Belly Ball is a solution for stress relief and improved digestion. I can certainly attest to the former — very relaxing. Often the best ideas are the simple ones. Give it a look.

Kindle DX

Wendy, ever the early-adopter, brought her new toy to work.

mark++ on the Kindle DX browser

Regular Copy vs Blu-Ray Managed Copy

The nice people at Blu-Ray are introducing managed copy next year. Try to contain your excitement.

Regular copy:

Blu-Ray “managed copy”:

Wow I’m sure that will be a big hit.

Comatose PC

A couple of my PCs occasionally slip into a coma from which I cannot boot them. I know these machines are just “stuck”, and not dead, because they eventually recover and work just fine for months.

It happens to my Linux server at home. On this machine the initial hang seems to be related to a problem with the PCI Wifi card.

It also happens to a Windows XP box at work. On this machine the initial hang seems to be precipitated by Windows automatic updates. (After install, it tries to reboot but only gets half-way.)

Once a system falls into a coma, it’s always the same infuriating crap:

Pressing the power button gives me lights on the case, and I hear disks and fans spinning, but I never get video or hear the “happy beep.” An instantaneous press of the power button at this point does nothing — I need to do the 5-second hold to power down. Reset is similarly useless.

If I hit the power switch on the power supply itself, or physically unplug the power, and wait for what seems like an utterly random time period (occasionally days, I kid you not) this sometimes helps. Eventually I plug it back in and it immediately boots as if nothing ever happened.

Dear internet, please help. I cannot construct a useful set of Google search terms to for this problem. Ideally, I would like a solution but I will also be satisfied with:

• A reliable way to rouse the machines from their coma
• An explanation of the cause for this, so I can properly direct my ire

Update 6/18/09: It appears that this problem, in at least one case, was likely caused by the power supply. Still working on the other one. Thanks for the suggestions.

Relocated

mark++ has officially relocated to wordpress.com. Please report broken links or other weirdness in the comments.

Meetings != Work

See that “empty” space on your Outlook calendar? You know, the stuff between the meetings?

Yea, that’s where the work happens.

Exercise for the reader: what does this mean for people with no empty space?

WebKit Never Gets Slower

I’m going to break radio silence to discuss this statement posted by the WebKit team on the subject of software performance. Summary: WebKit is fast because we’ve got performance tests and we never allow a regression:

Common excuses people give when they regress performance are, “But the new way is cleaner!” or “The new way is more correct.” We don’t care. No performance regressions are allowed, regardless of the reason. There is no justification for regressing performance. None.

I love WebKit (it’s blazing fast), and the team’s statement is very reassuring in that take-a-stand way. Unfortunately, I have to call bullshit.

Firstly, it’s important to note that a policy like this is only as good as your performance test suite. It’s very easy to accept a change which appears to have 100% positive benefit but is, in fact, a trade-off that you cannot measure because your test suite doesn’t tell the other side of the story. The WebKit team’s article admits as much, asking people to run their own performance tests and notify the team if badness occurs.

Even with an iron-clad test suite, we know software has bugs and that bugs must be fixed. One funny thing about high performance software is that, often, things can go really really fast when they are incorrect. I can optimize the hell out of any software provided it doesn’t have to get the right answer. To say that another way, bug fixes often regress performance. You can bet that the WebKit team fixes bugs. The product would not be useful otherwise.

Lastly, on what scale is the “no performance regressions” rule enforced? At most it can be per-check-in. It doesn’t take a genius to extrapolate from there. I’m sure WebKit has had plenty of check-ins which do more than one thing. Consider this imaginary check-in comment:

This change set refactors the Widget rendering code to make it more logical and less of a bug farm. It also memoizes the GetBestWidget function, improving performance on WidgetBench by 30%.

A cynical person (ahem) might say that this type of check-in actually does two, separable things, and that perhaps if we simply tolerated the original crappy bug-farm rendering code and added the optimization we’d have seen 35% gains.

Bottom line: things are never quite as simple as they seem.