The long journey to linux DVB

Copy your channels.conf file into ~/.xine or ~/.mplayer then start the player with gxine “dvb://TV CHANNEL” or mplayer “dvb://TV CHANNEL” This should get you going.

You could also try a far more manual approach shown here Cron is my TiVo

Freevo. When I was using Xine I kept having issues with nothing showing up or happening at all. There was two parts to this. First, the name of my channel has a space in it, so we need to put quotes around the command line in /usr/lib/python2.3/site-packages/freevo/tv/plugins/xine.py:158 so it looks like this:
command.append(‘”dvb://’ + tuner_channel + ‘”‘)
Second, make sure the channels.conf file exists in the ~/.xine/ directory of the user running freevo. I was sudoing to run freevo, so of course I had to copy my channels.conf file to the freevo user’s directory.

el cheapo webcam working

Finally, after several weeks, my cheap eBay webcam has arrived. I bought it because I needed a cheap and nasty webcam for Access Grid nodes, but I was also curious about it's linux compatibility… and it's all good. It works with the spca5xx driver.

Canon PIXMA IP1600, Dead at 4 months

The mind boggles why printers of this crap quality are even allowed to be produced.
Socially, this is really quite exploitive. I mean, most people who would by a cheap printer like this would do so for economic reasons, not because they thought that the printer would do the job, although in my case I knew it was a risk and thought I'ld test out the bottom end of the market. Now this printer has only just finished it's first ink tanks and not it just won't respond. Replacement tanks (Black and Colour) will cost about 80% of the cost of the whole printer!
So back to the shop for warrenty on this one, and that hopefully means an upgrade to a real printer.

When Mac OSX forgets it’s LDAP

The OSX server I administer is going
through a rather rough patch at the moment. First some security
updates disrupted the LDAP auth, then I accidentally delete the LDAP
database by setting the active directory to Stand Alone, then back to
Master replica. Of course it didn't ask if I intended to delete the
database, it just did it. But I've come to expect that by now.
So
the machine went back into service, and a week later there was a
power failure, and when the machine came back up LDAP auth was once
again broken. After pondering the symptoms for a while I decided that
the only possibility could be a corrupted LDAP DB. But that couldn't
be. I know BDB, the default back end for openldap is entirely manual
when it comes to recovery, but all Linux installs of OpenLDAP I've
played with (Debian comes to mind) automatically do a DB check and
recovery before starting slapd. Now Mac who have just repackaged
these OSS tools would surely have done some hardening and robustness
checking… Nope… The DB was broken, easily fixed by a db_recover.
But of course the BDB tools weren't shipped with Mac, so Fink to the
rescue, and after installing the tools for BDB 4.1, and a quick
change to the LDAP startup script (/System/Library/LDAP/LDAP) to do
the Linux style DB checks, everything is flying again…
Not that
I'm on a Mac knocking trip or anything, but I really don't think it
was worth the extra money to run with a Mac server. The reason we did
was the main computer person on site, who is by no means a
technician, knows something about Mac, and we were promised that Mac
had built nice, usable, intuitive, and integrated front ends to all
the server features. As it has turned out I've spent more time fixing
this system, and doing the routine tasks which the on-site person use
to do on the previous Linux server. Why? I really do think that Mac
is Linux + Hype + Random reorganisation of directories. For what we
do, which is a PDC + Print server for a W98+WinXP domain, an SME or
even a Debian server would have been less work, with more uptime, and
less cost.

My .bashrc

# ~/.bashrc# Make the prompt in the for user@host:directoryexport PS1='\u@\h:\w\$ '# Eliminate duplicates in your command historyexport HISTCONTROL=ignoredups# Make ls and ll colour, and ll show a complete list with human readable file sizes.alias ll='ls -lahi --color'alias ls='ls --color'

http://plone.jcu.edu.au/verg/resources/how-to/a-good-bashrc/view

Sometimes Java seems like a hack

I am using Java RMI to do the main IPC work for me, in a distributed number crunching application. Now the reason I’m using Java for this is another story, for another time. So, like any good developer I’ve got plenty of test cases, but one of them just never seemed to exit. So I fired it up in Eclipse and paused the execution when it should have been finished, and what did I find? 1/2 a dozen RMI related threads. But I unexported the objects, and cleaned everything up… Well according to this that isn’t enough. The only way to fully shutdown an RMI server is with System.exit(0).

Why? did the implementation get too tricky, and they decided to leave the cleanup to the operating system? Oh well, lets see if we can drop RMI now! I hear Jini is good. I just hope it doesn’t inherit this same problem.

Pet hates

Current pet hate. RSS feeds which have only the title, and the title again in the body, or even just the first sentence. What is the point?