Friday, August 28, 2009

Three annoying things

1. TV advertisements that say things like "eliminates up to 100% of dandruff flakes" or "up to 100% grey coverage" - typically ads for shampoo and the like.
Like, I can defeat up to 100% of ninjas by doing nothing, since "up to 100% of ninjas" means "x ninjas, where 0 <= x <= the total number of ninjas". A building could be up to 100% demolished by throwing a large rock at it, which is to say that it will be only very slightly damaged. Saying that a shampoo removes "up to" 100% of dandruff is saying nothing.
Stupid wishy-washy meaningless-statement-making assholes.

2. People who stand at a pedestrian crossing but don't hit the button, presumably on the assumption that they will automatically get a green light and the button does nothing but tell them to wait for the scheduled light change which would have happened anyway (which is only sometimes the case).

There are some crossroads where the pattern is like:
(A) west turning south cars only (and pedestrians crossing between NW/NE or NE/SE if the button was hit in the previous A, B or C),
(B) east and west cars only,
(C) north and south cars only.

If a pedestrian hits the light switch on the northwest, northeast or southeast corner, then they can cross at the next A.
What happens about 20% of the time, is that one or two plonkers stand at one of the lights and wait until A, upon which they still don't get a signal to cross because they never hit the button. Then they frown in confusion and eventually jaywalk at the next opportunity, cursing the system. Or you arrive at the crossing, mash the button and grimace at them, having watched them stand there like a muppet for about 30 seconds and miss the crossing timeslot.
Dumb. If you're standing in front of the button, just fucking hit it.

3. People who cross a road and casually hit the button as they walk past, even though they're not going to wait for a crossing signal. Instead, cars and cyclists have to stop and wait uselessly for nobody to cross, since the guy who hit the button is already out of sight, back on the pavement.
If you're going to just cross the road anyway, DON'T hit the fucking button!

Thursday, August 20, 2009

Software patents: broad, stifling and unfair

(posted comment on ZDNet article "Examine the patent that made selling Microsoft Word a crime")

The problem with patenting processes or algorithms - not necessarily even in computer software - is that we end up with extremely broad or obvious patents whose sole purpose is to allow the patent holder to eventually sue large companies and get (obscenely) rich, and not to safeguard investment in new inventions and products as was originally intended.

If you write a program using simple common sense and happen to "re-invent" something that's patented, that's a strong hint that the patent is too general or obvious.

This is why we have ridiculous patents on "not having to click on a control for it to display dynamic content in a web browser" (Eolas), or "method of swinging on a swing" (United States Patent 6368227, which in itself should be evidence that the US patent system needs to be destroyed and rebuilt by people with an IQ above 30).

What's next? "A method of lifting heavy objects by using one's legs, not one's back"? Or, following Eolas's lead, "not having to say 'abracadabra' and turn around three times before turning on a computer"?
And how is $280m a reasonable amount of "damages", when i4i has produced nothing that could be damaged? Where is their competing product which is suffering in the marketplace due to competition with the patent-infringing Office?

And to those arguing that Microsoft/everyone should do their "due diligence" by researching patents, have you ever written a computer program? Can you really imagine searching for patents that might cover every single aspect of the code you're writing?
Programmers produce code that solves the problems at hand. They do not think "hmm, maybe what we need is to store some text separately to where the formatting information for that text is stored. That makes sense. Better check if that is software-patented!"
Imagine trying to speak to someone while having to look up every individual word you use to check that it's not in some arbitrary blacklist. It would be an unproductive nightmare.
And on top of that, patent search is extremely difficult because they're often worded in an inconsistent, generic or confusing way.

Software patents do nothing good for anybody other than patent trolls and lawyers. For everyone else in the world, they only hold back science and progress. Get rid of software patents in the US now, and keep them out of the EU too.

Wednesday, August 19, 2009

OS X panics

A recent kernel panic on my Macbook looks quite familiar - I think it's been happening now and then since I got the machine in late 2007. This time, and probably most of the other times, it was showing video on Youtube, which suggests there might be a bug in the video driver (or err... the video card :/), but there's not much information to base a confident guess on.

The crash report looks like:
Tue Aug 18 17:58:36 2009
panic(cpu 1 caller 0x00194B15): "pmap_flush_tlbs() timeout: "
"cpu(s) failing to respond to interrupts, pmap=0x46c7ae0 cpus_to_respond=0x1"
Backtrace (CPU 1), Frame : Return Address (4 potential args on stack)
0x343f3be8 : 0x12b4c6 (0x45ec20 0x343f3c1c 0x13355c 0x0)
0x343f3c38 : 0x194b15 (0x465018 0x46c7ae0 0x1 0x195234)
0x343f3ca8 : 0x197eb4 (0x46c7ae0 0x26b46000 0x0 0x0)
0x343f3d88 : 0x16087d (0x46c7ae0 0x26b46000 0x0 0x71f9)
0x343f3de8 : 0x163170 (0x1c67c40 0x46c7ae0 0x26b46000 0x0)
0x343f3f58 : 0x1ab39c (0x4f7983c 0x26b46000 0x0 0x3)
0x343f3fc8 : 0x1a15fd (0x68b8900 0x0 0x1a40b5 0x68b8900)
No mapping exists for frame pointer
Backtrace terminated-invalid frame pointer 0xbfff7e88

BSD process name corresponding to current thread: firefox-bin

Mac OS version:

Kernel version:
Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009;
System model name: MacBook2,1 (Mac-F4208CAA)

System uptime in nanoseconds: 810215756731744

A quick Google turned up mostly useless assertions on forums like "it's probably a faulty logic board or memory stick - reboot into single user mode and run memtest". In my experience, when memory goes bad, it's much more impressive than an occasional (something like once every month or two) panic. Searching a bit more carefully, I turned up some kernel source code released by Apple (cool!):

xnu-1228/osfmk/i386/pmap.c -> pmap_flush_tlbs(...)

if (cpus_to_signal) {
deadline = mach_absolute_time() + LockTimeOut;
* Wait for those other cpus to acknowledge
for (cpu = 0, cpu_bit = 1; cpu < real_ncpus; cpu++, cpu_bit <<= 1) {
while ((cpus_to_signal & cpu_bit) != 0) {
if (!cpu_datap(cpu)->cpu_running ||
cpu_datap(cpu)->cpu_tlb_invalid == FALSE ||
!CPU_CR3_IS_ACTIVE(cpu)) {
cpus_to_signal &= ~cpu_bit;
if (mach_absolute_time() > deadline) {
force_immediate_debugger_NMI = TRUE;
panic("pmap_flush_tlbs() timeout: "
"cpu %d failing to respond to interrupts, pmap=%p cpus_to_signal=%lx",
cpu, pmap, cpus_to_signal);
if (cpus_to_signal == 0)

I won't make any pretense at understanding most of this, but it looks like, for that panic to occur, the condition (!cpu_datap(cpu)->cpu_running || cpu_datap(cpu)->cpu_tlb_invalid == FALSE || !CPU_CR3_IS_ACTIVE(cpu)) is never met, so we keep waiting and checking until our deadline passes.
The timeout appears to be 12500000 mach time units, which apparently are equivalent to nanoseconds on my laptop - so 0.0125s, or 1/80th of a second.

So if we revisit that condition, we can assume that we get to a stage where, for at least 1/80th of a second, the inverse of the test is always true (or happens to be, every time it's checked - could be a race condition I suppose?): (cpu_running && cpu_tlb_invalid && CPU_CR3_IS_ACTIVE(cpu))...

I'm too lazy to look up what CPU_CR3_IS_ACTIVE(cpu) (a macro that expands to ("(cpu_datap(cpu)->cpu_active_cr3 & 1) == 0)") signifies, but the whole CR3 mess is some kind of i386 control register for dealing with virtual memory paging. Beyond these most basic observations, I'm pretty clueless about the problem, so would love to hear from anyone if you have any ideas.