127.0.0.1 is not alive
what can I say about the hell I've been living on? let's try this: sell japanese food to dogs. they don't have a damn clue about what they're buying, they don't have a damn clue about how much effort it takes, they don't have a damn clue about how much time it takes and they bark at us as our team is a bunch of incompetent idiots. *sigh*

scooby everywhere
now working "only" 8~9 hours by day, there's some spare time (and will) to play a bit. I made a sample linux kernel module to make available a bunch of contiguous memory pages to user level through mmap() for a friend. he needs a way to get an amount of physically contiguous memory and its address in user level so it can setup a video grabber to do overlay in that address (video4linux 1). he also needs to have access to this memory region. the way it's done today is using video card's memory. if you find this interesting, it's available here. it surely contains a bug, triggered by the second execution. home work! :P

SCC: breaking your software since 2005
users are great. really. when you get used to linux, you simply don't mind of doing things manually even when it should work at first time. I met this week in IRC an user who has the same notebook I have and he noticed that you should do insert/remove/insert everytime you want a card detected by cardbus controller. it happens since 2000 and I _didn't_ noticed this! it surely isn't a hardware problem since it works in OpenBSD and Windows XP in the same notebook. while doing some simple debugging I noticed the event register is simply empty in the first insert and then when the card is first removed, it comes with right value and in second insertion too. the linux' yenta interrupt handler looks a lot like OpenBSD's, so seems this is a bit more complicated than I thought before. oh fun, fun, fun!

by any chance, do you use any SCM?
quilt rules. at work we have a svn repository but before each of us commit anything others should review first and in case of an "experimental" changeset, everyone should do some testing. because of this, quilt is being so great: we're exchanging patches among us quickly in a simple way. I plan to write some sort of tutorial on these quilt "use cases" soon. and maybe creating a "quilt compare file" to quickly open vimdiff (or equivalent) to make easier to review code you don't know so well.

why write a driver? isn't ioperm() enough?
thumbs is staled for some months. I'm almost buried alive in so many bug reports and feedback on -alpha1 (none). uinputd is being slowly developed. cabal repository didn't had any commit since that tuesday, the last day before I got my tickets to concentration camp.