Friday, August 11, 2006

New York Times needs to correct the correction

Gateway Pundit has a story about a faked picture in the New York Times. It shows a picture of an apparently dead man being "pulled from the rubble", and that's what the caption in the Times said. But it turns out that the corpse was assisting the cameraman earlier in the shoot. The Times "corrected" the story with the following:
The man pictured, who had been seen in previous images appearing to assist with the rescue effort, was injured during that rescue effort, not during the initial attack, and was not killed.
Don't let them get away with this. The picture is obviously a posed shot, not a picture of someone injured. The man is pretending to be dead or unconscious yet is holding his hat under his arm. The other man is clearly pretending that the fallen man is dead; you don't help an injured and unconscious friend by grabbing one arm and pulling him up. There are other rescure workers in the background looking on. If someone had just fallen and injured himself so seriously that he was unconscious, would the other rescue workers just stand there and watch?

This is obviously a staged photo of a dead guy being pulled from the rubble of a bombed building, not a genuine photo of someone who was injured during rescue operations. The mistaken caption could be put down to a lying photographer, but the correction must be blamed on dishonest or incompetent editors.

Wednesday, August 09, 2006

what else would you call them?

You know those Bluetooth cell-phone headset thingies that people wear looped around their ears? Some people who wear those things don't like it when you remark on their Borg implant. But what else would you call it? It's not really a headset, it's not really a phone, it's not really headphones. And you can't go around talking about "those Bluetooth cell-phone headset thingies that people wear looped around their ears", so it seems like "Borg implant" is a pretty good name.


I'll be hosting the next Storybloging Carnival here next Monday. If you write stories for your blog, I'd love to get an entry from you. Send me your entry by Saturday night with the following information:
* title
* story URL
* author name (optional)
* blog name
* blog URL
* word count
* content rating (like G, PG, R, etc.)
* a short blurb describing the story

Tuesday, August 08, 2006

I wish I'd said that

Dean Barnett is guest blogging over at Hugh Hewitt's site. Barnett seems to view this as a coup, but I think it's a coup for Hewitt. I like Hewitt a lot, but pound for pound, few bloggers can match Barnett for his combination of insight and piercing prose.

This analysis of the Democrat party pretty much says in one post what I've been trying with indifferent success to say about the Democrats since I started this blog. With Barnett out there, why do I bother writing on politics? Maybe I should stick to engineering from now on.

queues and commodes

In anticipation of future growth, my company has been using a much larger space than it needed. Lately, the predictions of growth are coming true and we are experiencing lines at the restroom for the first time. To make matters worse, we occupy one half of a floor and the other half has been empty, but I've seen signs that someone may be moving in next door. There is only one restroom, so that means longer lines. Now, your average mortal human would probably accept this situation with an air of fateful resignations --there are only so many commodes, there are too many people who want to use them, so you have to wait in line. But the people in my department, we are not average mortals; we are engineers.

Engineers don't just go "Oh well" when we see a situation we don't like; no, we are compelled to analyze the situation, to abstract the problem, to propose solutions. And not just any solution, such as sabotaging the other half of the floor to make it unsuitable for office space, but a mathematical solution (not that this suggestion didn't come up, I’m not saying it did or it didn't, just that it wasn't a typically engineering solution. If it came up, that is). And since we aren't actually getting paid to deliver, we have the delightful luxury of analyzing it to death and forgoing all of the boring implementation details.

Now commodes may be modeled as resources and the users of the commodes may be modeled as tasks that need to access the resources. Part of what makes something a resource (in computer jargon) is that it is limited: only a certain number of tasks may access a resource at one time, and the total number of tasks is larger than the number that can access the resource at once. This means that if the number of people who need to use the restroom at a given time is larger than the number of commodes --the number of tasks that need to access the resources is larger than the number of resources available-- then some means of sharing the resources must be implemented. Our goal, as engineers, is to find the optimal algorithm for sharing these resources.

The number of possible solutions is very large, and so we must put certain constraints on our solution. We assume that once a task has acquired a resource, it cannot be pre-empted, it owns that resource until it is finished with it. This rules out solutions such as trap doors before the urinals and ejection toilet seats that can be used to remove unwanted occupants. I'm not saying that these pre-emptive solution were or were not suggested, simply that they were (eventually) ruled out of the model for pragmatic reasons.

The default solution to this problem in the case of bathroom resources is standing in line. A speaker of British English might say that one waits in a queue, and a computer scientist might say that one is inserted into a FIFO queue. FIFO stands for First-In First-Out. This doesn't just mean that the first one in is the first one out, it means that if you pick any two objects in the queue at any time, the one that got into the queue first will be the one that gets out of the queue first (assuming that both objects exit the queue before the process terminates).

FIFO queues are not the only kind of queues. Suppose the bathroom is organized like this: when you enter the door and see that the commodes are all occupied, you step to the entrance of a very narrow hallway inside the bathroom. If someone else comes in while you are waiting, there is no room for him to get past you, so you have to back up into the narrow hallway and he stands in the entrance. Then another person comes in, and you and the person in front of you both have to back up further to let the third person stand in the hallway. When a commode is available, then you can't get around the others in the hallway, so the one who came in last uses the newly available resource and you and the other guy step forward. When another becomes available, the guy who came in after you uses it because you can't get around him. Finally, you get the next one. Unless someone else comes in before a commode is free and you get pushed back in the hallway again.

This kind of queue is called a LIFO queue, Last-In First-Out. It is also called a stack, a reference to the stack of trays in a cafeteria (the ones one on those spring-loaded counters so when you take trays off the top, the springs raise the remainder of the stack up so the next one is easier to reach). Stacks really aren't used much as a form of resource allocation, they are used more for a way of organizing things that have to be done later. And the reason should be obvious. The person at the bottom of the stack may never get to use the resource because others keep coming in before his turn comes up. There is a computer science term for this, which you may be relieved to know comes from a non-bathroom analogy; it's called starvation.

Clearly it is unreasonable to have some poor sucker stuck permanently at the end of the line, squeezing his legs together and praying for a fire drill, so we will have to add another constraint to our solution: no starvation. But this isn't quite strong enough. All it means to say "no starvation" is that every task will eventually be able to access the resource, but that's not enough. We need to say that every task can access the resource within a reasonable time. But what is a "reasonable time"? That is something we will have to come back to.

To be continued.

Sunday, August 06, 2006

review: Logitech Bluetooth mouse and keyboard

When I got my new laptop a few months ago, I also bought a Logitech Bluetooth mouse and keyboard. I bought these because I've had a Logitech Wireless Deskset for almost ten years now and it was worked flawlessly, but it uses the old-style connectors and my new laptap only accepts USB periphals. I could have picked up another one of the same product in USB, but the advantage of Bluetooth was that I needed a Bluetooth receiver anyway to connect other Bluetooth appliances, so this would let me reduce the number of attachments.

It was one of the most disapointing purchases I've ever made. First, I couldn't use the Logitech Bluetooth receiver to connect either my cellphone or my headset. I don't know who is guilty of not following the standards: Logitech or Motorola, but it didn't work.

That was the least of the problems. Neither the keyboard nor the mouse works properly. The keyboard often misses keypresses, including the SHIFT and CONTROL keys, which can change the meaning of a command. Even worse, it sometimes doubles keypresses. I can press DELETE once, and the keyboard sends two DELETEs. Instead of deleting one email message, I delete two, and it happens so fast that I could easily miss it (don't think I've missed it yet). This is a frequent and serious problem.

The mouse is just as bad in a different way. I haven't noticed it missing button presses or doubling button presses, but it often gets into a delayed response mode. During these times I can move the mouse in a circle, and the pointer doesn't move at all. Then ten, fifteen, even thirty seconds later, the mouse pointer will move in a circle. Sometimes these delays seem to be related to high-intensity computation on the computer. For example it gets worse during 3D games when there are a lot of figures on the screen. Other times, it seems to be completely random. This, too, is a frequent problem that can make my computer almost unusable for long periods.

Besides that, the product suffers from feature inflation. The keyboard has "multimedia" keys and a "multimedia" touchpad. I have no use for these things, but I couldn't just ignore them because they are active by default. I would accidentally pres one of the buttons while picking up the keyboard and then have to sit and wait while some huge multimedia application started up just so I could close it. Even worse, the function keys by default were set to special actions. I use function keys all the time in my applications, so I had to figure out how to turn off the special actions. All in all, I must have spent a couple of hours getting the keyboard to just be a damn standard keyboard.

The mouse also has tons of buttons that are often pressed by accident and need to be turned off. Unfortunately, the option "do nothing" is not available for mouse buttons, so you have to find something harmless for them to do. I like to set the middle button (the mouse wheel, when you press it down) to be double click. Saves my index finger a lot of clicks over the course of a day. I've been doing that with every mouse I've owned for ten years. Never had any problems with it --until now. This Logitech Bluetooth mouse won't do it. I don't know why; the setting is there, but it just doesn't work. Other buttons on the mouse can be set to do double click and they work. But not the one I want.

I strongly recommend against buying the Logitech Bluetooth mouse and keyboard. They are bug-ridden, useless-feature-ridden monstrosities.

UPDATE: I just remembered that I found out the problem with the phone was on Motorola's side. Motorola's USB/Bluetooth connections don't follow standards.