Firewire mess

Yesterday I stumbled upon a task to transfer few recordings from miniDV camera to my laptop. The camera had the iLink output, so did my laptop. I thought that this should be easy. It wasn't.

I prefer to use Debian kernels. Since 2.6.22 they have disabled old ieee1394 stack in favour of new 'juju' one. OK. But the libraries still aren't updated to use it. Fine. Let's build them. Needless to say, that even with libraw1394 updated to include juju supoprt, dvgrab failed to work.

After some experiments I decided to surernder. After a couple minutes, I've built the old ieee1394 stack, fired the dvgrab with original libraw1394 and started grabbing w/o any major glitches.

I won't ask, why the experimental and still uncomplete stack was merged into mainline kernel. I won't ask, why applicatoins still aren't fully updated to use it. But why the hell did Debian kernel maintainers disable old ieee1394 stack?! If they enable such "beautiful" features, why won't they switch off most of the IDE subsystem in favour of PATA which is much more mature?

distros

There are a lot of differencies between Ubuntu and Debian. It's nothing wrong with having some. OTOH some of them are very... frustrating. E.g. there is still no IcedTea for Debian, but there are Ubuntu packages with it. From my point of view, it's really strange.

Generic pointers mess

One of my latest bugs gave me 4 days of vandering in the dark. I was getting really strange warning from the lockdep when I was enabling clocks on tmio chip. The code was 1-to-1 converted from working one, so there shouldn't be any problems. But there were. After double-checking all locking logic, increasing lockdep constants to really big values and even looking into lockdep details, I finally found the source of the problem: as a private data I passed not the structure I exected to receive.
Pretty trivial problem for a language w/o runtime type checking functionality. Maybe it's time to implement it
as a wrapper around various magic values and type checking functions? In the userspace IIUC glib permits smth. like that, it manages a class-based system with objects allocation, etc. Would I like to see smth. like this in kernel? Probably no. Would I like to see some generic way to enable such checks for objects like spin locks, mutexes, etc? Definitely yes.