Dan's Demented Ramblings

Apple recently announced the latest ( and smallest ) in their line of desktop PCs, the Mac Mini

This sweet little thing is just what you need in the Kitchen/Family room to

• Check email
• Write up your shopping list
• Look for recipes
• Play a little music

The sky’s the limit.

It could also sit in the theatre room hooked up to your HiDef projector via DVI and let you surf the net on a BIG screen or play some of those DivX/XVid programs you downloaded off the net.

You can get it with 802.11g and Bluetooth to save on the cable clutter.

You’re not going to believe this one….

I got a call from a long-time customer of my employer ( it was my turn with the pager 🙁 ) at approx 3:00am on Monday 20/12/2004 reporting that a SCO machine on their network had gone down and that their investigations pointed to our machine ( also running SCO ) as the culprit.

As the machines in question had been installed and running for approx 6 years and neither machine had been modified in quite some time, I was to put it mildly, sceptical of their conclusions.

After a day of sifting through the system, application and other logs ( thanks mostly to the excellent sar utility from the Sysstat tools ) I came to the conclusion that one or more processes on our system had suddenly become very active, but I was unable to determine the identity of the culprit.

One thing I did notice was that the uptime was approx 248 days.

I passed the analysis on to a colleague who found that there is a known bug ( OSS456B ) in some versions of SCO OpenServer that result in unpredictable behavior once uptime exceeds 248 days, some sort of internal integer overflow error.

In the case of our machine, once the magic number was hit it started broadcasting packets to any SCO Licence daemons on machines connected to the network at an enormous rate effectively mounting a DoS attack on any machines listening on the desired port.

Why is it so hard to find a half-way decent personal finance app, that works on your platform of choice and doesn’t cost the earth??

If you’re a windows user then no-probs, Quicken have a nice product for the home user Personal Plus, you can also use Microsoft’s personal finance product Microsoft Money 2005.

For those of us anarchist non-windows types we can use Quicken 2005 for Mac if we own a mac AND are in the United States, no localised Australian version for us even though all the Quicken windows products are available here.

If you run Linux then you’re buggered, there are many Open source products in this category but few are more then toys and none fully replicates the feature sets of the low-end windows products.

Probably the best bet is GnuCash which does most of what you need for a Personal Finance App, but is missing two of the most useful features

GnuCash Runs on Linux and Mac OSX, there are no plans for it to be ported to Windows but you never now.

1) Budgeting – Allow you to set spending limits on categories and track your spending against these limits.

2) Debt Reduction Scenarios – The ability to determine the best way to allocate extra money to your current debts and prepare a plan to get out of debt. From memory this is handled very well in Quicken’s products.

Maybe I should go back to a spreadsheet, but it’s such a pain in the ass that it won’t get done, oh well, back to the salt mine….

There is an interesting interview Ten Questions with TiVo’s Director of User Experience, Margret Schmidt that talks about how TiVo designed what I consider one of the best and most intuitive UIs ever.

I have looked at the interfaces on several PVR and Set top boxes of late and even though these devices were designed 8 years after the first TiVo, they are as a whole hugely inferior to the TiVo in regards to the UI.

Part of the problem is that most of the current players in the market are ignorant ( deliberately or otherwise ) of their competition and so miss the opportunity to profit from their mistakes.

In the case of TiVo as it is only a US or UK product, the competition ( mostly out of Korea or India ) can’t typically acquire or use one well enough to get a feel for the interface design.

TiVo have certainly shown interest in licencing their technology to hardware manufacturers, it would nice if they could develop their software into a platform in a similar way to the Symbian Series 60 platform used by most of the major mobile phone manufacturers in the world.

I’ll keep my fingers crossed ….

The problem with the test program turned out to be a lot more mundane then I thought.

The serial port on the Topfield defaults to 115200 baud, the IceLink dongle runs at 9600 baud.

My terminal program is set to its default of 9600 baud which works beautifully for the IceLink, the very first thing the IceLink Interface TAP does is to set the baud rate to 9600, it returns the baud rate to 115200 on exit.

The short version, running IceLink Interface sets the serial port to 9600 so my test program displays as per normal, not running it leaves it in 115200 baud so I get a rubbish character on the screen.

Case closed, move along, nothing to see here….

But seriously..

The moral of the story as is often the case when debugging is this

“If you see hoofprints, look for a horse, not a zebra”

or “Look for the simple solution first, leave the exotic ones for later”

I discovered the true nature of the bug in just a couple of minutes by inspecting the good app and comparing it with the bad. The TAP_Baud function stuck out like dogs balls, I would have noticed it in the first place if it wasn’t 9:30pm after a full day at my day job and a 4 hour session of fiddling with Makefiles, includes etc to get a sane dev environment for the Topfield.

Last night Rick ( a colleague of mine from IceTV ) and I were working on adding the Topfield TF5000PVRt Terestrial Digital PVR to our unified development environment.

After much stuffing around due to some serious oddities in the libraries provided by Topfield, like standard C functions in the header files that are not included in the library making it hard to define your own replacement versions !!!, we ended up discovering a Heisenbug.

The symptoms are that our test program would only run successfully if another completely unrelated application was also running on the PVR!

That’s some freaky shit….

Initially we thought it might be the fact that the other app is ~ 64Kb in size and is pushing the test app into another section of memory, to test this we tried creating a bogus app that did nothing except allocate 64Kb of memory into a buffer.

We ran this app INSTEAD of the one that resulted in a working system, unfortunately this didn’t result in a working test program so the answer is something else.

I intend to dig into the problem tonight and see if I can resolve it.

Watch this space …..