Kasperian Moving Parts

kinda like batman, but with a wife and 3 kids

Tuesday March 3, 2009
by Jason 'vanRijn' Kasper
29 Comments

A Tale of a Flat Tire and God’s Goodness

I pray a lot for my kids. I always have. I ask God to protect them, shield them, guide them, and watch over them when I cannot. Watching your oldest child reach 18 years of age, start college, start driving, and be out of your line of sight and protection for large parts of the day make you pray even more. And so it is that I missed God’s blessing entirely and went straight to angry, pissed off, frustrated, groaning, belly-aching, and in general no fun to be around this morning when my darling bride and I drove both cars down the driveway to get the annual vehicle inspections done.

Thankfully, I noticed the flat tire about 30 yards down the road from our driveway, so I pulled over, checked it, (went straight into pissed-off-mode), and turned around and went back home. It’s snowy, slushy, icey, and cold right now in Douglas, MA, so it was all that I could do to barely get the car into the bottom of the driveway. I’ve never had to drive on a flat tire before, but this time I had no choice. I’ve heard all kinds of bad things can happen as a result, and I was most worried about ruining the wheel or axle or something. So I pull into the driveway, open the trunk, and discover that the trunk has been leaking water again (or allowing it in through the bottom… I don’t know which), and now that it’s winter in MA, it has frozen solid inside the trunk. The trunk wheel well was about half full of frozen water, surrounding, enclosing, and including the spare tire. An hour and a half later, after failed attempts with a heat gun and a steam cleaner, I used a 20-pound steel pry bar to pry the spare tire loose from the trunk. I now have a Flinstone-car-looking ice block that looks like a tire. Another 15 minutes with the steam cleaner to get spare tire free of the ice, and I put the spare on and inflated it.

Now we’re on our way to the inspection station. Turns out that (I think) the reason the tire was flat is because it was so under-inflated that the bead seal just failed and all the air leaked out. However, being that I drove on it for a couple of minutes while it was flat, the tire is now unusable (steel belts destroyed and air bubbles are now in the sidewall). $70 later for a replacement tire, and a Russian immigrant mechanic to tell me “your tire no good”, and we’re on our way again.

And then it hit me. This was what I asked God for. This is what I’ve been praying for. Not necessarily to have a flat tire, ruin an whole day of work, not be able to get the spare tire out because the entire trunk is a big ice cube, and to waste $70 on a replacement tire. No, I distinctly do not remember asking God for that. But I’ve been praying for my kids’ safety for their whole lives, and that is exactly what God did for me. If this would not have happened to me today, it would have happened to my eldest daughter tomorrow, who likely would not have known to check the tire because it felt smushy, and who very well may have gotten into a really bad car accident, or been stranded, or worse, as a result. Thank God that this happened to me today instead of her, tomorrow. And as I was moaning, griping, cursing under my breath, freezing, frustrated, and angry, it occurred to me that God was being extremely gracious to me and my family once again. Who am I to question how God answers my prayers and keeps my family safe?

Thank you, God. And I’m sorry for going straight to anger, frustration, and pissiness and missing your blessings.

Oh, and you cannot tell me that God does not have a sense of humor, after a day like this. =:P

[Update] Wow, people can be incredibly rude, insensitive, and insulting. I’ve deleted the idiotic vitriole that found its way to this posts’s comments, and have turned further comments off. Thanks, idiots!

[Update2] I’ve decided to turn comments back on here. Unfortunately, I deleted the previous hateful, rude, insensitive, insulting comments instead of moderating them, so I am unable to bring them back for your enjoyment.

Thursday February 12, 2009
by Jason 'vanRijn' Kasper
9 Comments

My Childhood Guinea Pig Named Squeaker

<kergoth> anyone messed with protobuf?
<vanRijn> kergoth: i once had a hamster i named protobuf, does that help?
<kergoth> fraid not
<vanRijn> actually, it was a guinea pig
<vanRijn> and it was named Squeaker
<vanRijn> but still
<darth_mall> vanRijn: that’s practically the same thing!
<kergoth> hehe
<vanRijn> darth_mall: I KNOW RIGHT!

I think I’m getting too in touch with my emotions as of late. I actually got a little teared up, thinking about my cute little childhood Guinea Pig named  Squeaker and his untimely demise.

*sniffle*

Wednesday February 11, 2009
by Jason 'vanRijn' Kasper
9 Comments

Screencasting in Linux!

I’m excited. I love learning stuff, I really do. I just did  a 12-minute screencast for work, and I think I’ve finally figured out how to get everything to fit together nicely. I’d never done a screencast before–not on any platform–but being that I needed to showcase some development work that I’ve done for the next release of VMware Workstation/Player, and being that I’m working from home for the time being, I needed to get this all working in Linux, and as I said, I think I’ve finally figured it out, woot!

For starters, I used qt-recordMyDesktop to capture the full-screen (1600×1200 resolution) video. I wanted to use it to also capture the audio portion of the screencast at the same time, but when I tried doing so, the audio was really choppy and out of sync. I mostly blame pulseaudio, but also the fact that I did this all on my puny little laptop, and I think that the system just wasn’t able to keep up with me, recording a nested Xephyr session with 4 fake Xinerama monitors (thanks again for that beauty, Lubos!), at 1600×1200 resolution. So I told qt-RecordMyDesktop to not capture audio and what I ended up with was a beautiful 1600×1200 Ogg/Theora .ogv file. We’ll call it demo-video.ogv.

Next, I recorded my voice, doing a monologue of what was happening in the screencast, using my laptop’s internal mic (not the greatest quality, but I don’t have a real microphone, *sigh*), and audacity (oh, and this is nice… audacity doesn’t work with pulseaudio whatsoever). This I saved in mp3 format. We’ll call it demo-audio.mp3.

The next magical trick, obviously, would be to combine the audio and video files into a single movie file, right? Well, all of the questions/answers that Google found me (even though I searched for “mencoder combine audio video”) were examples using ffmpeg. So I gave it a shot. And I’m sure there must be a way to do it, but for the life of me, I couldn’t get ffmpeg to combine my 80-meg demo-video.ogv file and my 10-meg demo-audio.mp3 file in a high quality and problem-free output file. The closest I think I got was this: “ffmpeg -sameq -i demo-video.ogv -i demo-audio.mp3 demo_full.mp4″, but that combined my 80-meg video and 10-meg audio file into a 350-meg mp4 file. Zoinks, Shaggie!! That’ll never do!

I finally stumbled upon the “-audiofile” parameter to mencoder and there was much rejoicing in Agrabah (not to mention Massachusetts). What I ended up with is this little mencoder incantation that seems to work beautifully. And, the resultant file is only 62 megs (80m + 10m == 62m !?!), so I’m sure there’s some loss of quality in there somewhere, but for the life of me, I can’t see it. Here’s what I used:

mencoder -sws 9 -vf pullup,softskip,scale=1600:1200,harddup,unsharp=l3x3:0.7 -oac faac -faacopts br=128:mpeg=4:object=2:raw -channels 2 -srate 48000 -ovc lavc -lavcopts aglobal=1:vglobal=1:vcodec=mpeg4:acodec=libfaac:abitrate=128:vbitrate=1000 -of lavf demo-video.ogv -audiofile demo-audio.mp3 -o demo_full.mp4

So, there you have it. Screencasting, done 100% in Linux. I wish I could show you the results, because I’m pretty darned please with them, but sadly, I cannot (nor do I have a spot to stick 62 megs of mp4 =;P).

I hope this helps some other poor soul, ’cause I couldn’t find much in the way of tutorials for doing this. I’d be very interested to hear what others think of this, as well as any other suggestions for doing screencasting in Linux. I know Aaron’s been doing something along these lines, and I’d be curious to see how this compares to his method. Also, any improvements to my mencoder line (yeah, I’m sure some stuff in there might be redundant or weird), or finding out what the ffmpeg equivalent of my mencoder line is would be greatly appreciated.

Tuesday January 27, 2009
by Jason 'vanRijn' Kasper
1 Comment

KDE 4.2 Released!!

Woohoo! KDE 4.2 is released!! I only wish the last few KPilot bug fixes would have made it into the 4.2.0 release, but we were too late. Still, if you think you knew what KDE4 was all about, think again. Check out KDE 4.2.0. =:)

Monday January 19, 2009
by Jason 'vanRijn' Kasper
22 Comments

KDE 4.2 KPilot coming! (how to both be excited and have realistic expectations)

I just sent this to the KDE PIM mailing lists, but I know not everyone who uses KPilot subscribes, so I’ll re-post it here…

Howdy all,

I just wanted to get a note out to as wide a distribution list as possible to spread some important news about the upcoming KDE 4.2 release and KPilot’s (exciting!!) part in it. If you don’t care about KDE PIM, data syncing, Palm devices, or KPilot, you may stop reading now and I won’t be offended. =;P

For the last 2 years, the talented Bertjan Broeksema and I have spent our Google Summer of Code months doing some major rework and redesign for KPilot. You can see our sync algorithm redesign Use Case here: http://snurl.com/acftl and some UML sequence and class diagrams that we used here: http://snurl.com/acfwd. Previous to our redesign, each conduit in KPilot contained all of the logic necessary for the syncing of record-based data, as well as the transformation, comparison, and resolution of that data. This means that each conduit did things its own way. We didn’t share any code between the conduits for syncing, and we weren’t consistent about how the data was synced. In addition, NONE of our conduits had the ability to synchronize category information from PC to Palm. We had inconsistent smatterings of success going from Palm to PC, but again, we were inconsistent and buggy. And obviously with this duplication of work, whenever a bug popped up in one conduit, it likely existed and had to be fixed (and most probably did not get fixed) in the other conduits. In addition, we did a very poor job of ensuring that we didn’t lose our users’ data, and subsequently, we had a bunch of “KPilot ate my future” e-mails (http://snurl.com/acgf0) that nobody was happy about.

So one of our most important goals in our KPilot redesign was the safety of our users’ data. We now go to great lengths at the beginning and end of the sync process to make sure that our record counts match between Palm and PC, and that we’re able to save all of our data successfully. If anything breaks in the process, we do not commit or save our changes to the Palm and PC sides.

We also didn’t want to keep writing and maintaining “how to sync” logic in our conduits anymore. This was a major design flaw previously and led to a lot of rework and problems. So we designed a record-based (since all of our syncing is from record-based sources) syncing conduit set of base classes that all of our new conduits inherit from. This means that now all of our conduits use the same syncing logic and flow. If we got it wrong, we fix it and now all of our conduits are fixed. If we need to improve the performance and efficiency (which we do, still), we fix it in one place and now it’s fixed and improved in all of our conduits. This is a much cleaner design and it means that our implementing conduit classes are now MUCH simpler, have MUCH less code in them, are MUCH easier to understand, and all follow the same patterns, meaning the learning curve for debugging, writing and contributing conduit code just became darned near close to flat. The job of our conduits is reduced to data transformation, comparison, and record domain knowledge, as it should be. The syncing logic all happens in the base classes.

Another nice feature that we added, although it’s not completely finished, is a final “volatility” check in the base conduit classes. At the end of the sync, we look at how many records we have created/updated/deleted in comparison to starting and ending counts, and if the changes are too volatile, we’ll ask our users whether they want us to save the sync or undo it.

Anyone familiar with programming in professional environments should be familiar with the idea of commit and rollback. Well, previous to KDE 4.2’s KPilot, we had one mode: change live data on the fly and don’t bother with commit/rollback. This made things nice and fast, to be sure, but we also lost a lot of data that we shouldn’t have. In fact, we didn’t even have a way to not lose data, previously. So this was another important design decision we made in the new version of KPilot. We do all of our syncing work in temporary storage and only at the end of a successful sync process do we commit (or rollback) our changes to the real (PC and Handheld) data stores.

We also have a nice new Keyring (http://gnukeyring.sourceforge.net/) conduit for KPilot which uses our new base syncing classes.  Unfortunately, we didn’t get a chance to finish polishing it off, and thus it will most likely be disabled for the final KDE 4.2 release. We’d love your help in getting it finished, though. Bertjan has even written a nice Qt4-based PC Keyring data file viewer/editor that we’d love to get finished, polished, and released. Please help!

So there’s a LOT of coolness in the upcoming KDE 4.2 version of KPilot. Not to mention the fact that it’s the first KDE4 version of KPilot. But I also want to set realistic expectations so that we’re all on the same level.

This will be the first release of a major rewrite of KPilot, and we have had very little user feedback thus far (although there have been a few very helpful folks and I really appreciate them!!!). This means that there are guaranteed to be as-yet-undiscovered bugs. I have been doing a bunch of testing and bug fixing, even since the last RC1 release of KDE 4.2, but there’s just no way I can hit all of the use cases we have. Things are looking extremely smooth and stable and I have not once lost data (yay!), but I’m sure bugs are in there, so make sure you make and keep a good backup of your Palm and PC data before trying new software.

Previous to KDE 4.2, KPilot relied on the external data sources to know about the condition of that data source’s records and PC->Palm  mappings, etc. With KDE 4.2, KPilot now keeps this information itself. This is a good thing! We had a bunch of problems in KDE3 which were caused by the mapping being wrong and/or the state being wrong (X-PILOTID and X-PILOTSTAT).  So we have our own XML-based mapping files now that are kept in $KDEDIR/apps/kpilot/conduits/<

username>/mapping/ and these help us to keep track of the mappings as well as per-conduit last-synced times, etc. We currently rely on this mapping to be valid at the start of a sync (which is also a good thing), but which has one unfortunate side effect that we’ll most probably not be able to get fixed before 4.2 is release: CopyHHtoPC and CopyPCtoHH don’t work as advertised right now. This also means that the first time you sync with the new KDE 4.2 KPilot, we will do a “first sync”, regardless of whether you’ve already synced with KPilot so that we can correctly establish this mapping file, and you’ll end up with a combination of PC and Palm data on both sides at the end.

We’re using Akonadi for syncing your data in KDE 4.2! This is also really good goodness! This will allow us (eventually, once the Akonadi back ends are written) to sync your Palm pilot with an Exchange data source, or a Google calendar, etc., etc. The realistic immediate view, though, is that KPilot is using and relying on a really new Akonadi solution. KDE PIM 4.2 is still not fully ported to using Akonadi purely, although we have bridge resources as an interim solution. This means that before you can sync with KDE’s 4.2 KPilot, you need to add an Akonadi resource for each data type (Calendar, Contacts, etc.), then change your KDE PIM applications to use that (korganizer, kaddressbook, etc.), and then reconfigure KPilot’s conduits to use those new Akonadi data sources. There are glitches to be found in all these layers, to be sure!!  In my testing, it looks like you have to hit reload in korganizer to see kpilot changes to akonadi’s cache after a HotSync, for example. Also, it’s a manual process to convert your PIM data sources to Akonadi resources so KPilot can sync with them. This MUST be done, since KPilot now syncs only with Akonadi data sources. Together, we’ll be finding (hopefully just a few) bugs in KPilot, the new KDE PIM code, and Akonadi. The pay-offs for all of this work are immense, but we need to have realistic expectations about it too.

We have a serious developer shortage in KPilot–both real-person-resource as well as available-time-resource–and as a result, we were only able to bring so much forward from KDE3’s KPilot into KDE 4.2. We tried to focus on the most widely used functionality and, to be honest, that which we the KPilot developers actually use. This means that KDE 4.2’s KPilot will not have: the Knotes conduit (which was badly broken anyway), the DOC conduit (which I’d love to get working again but we’ll need someone to help code it to get it done), the Avantgo/MAL conduit (does _anyone_ actually use Avantgo anymore???), the popmail conduit, or the notepad conduit. So, if you absolutely have to have one of those, please continue to use the KDE3 KPilot, or better yet, help us port your favorite conduit to KDE4!!! What we do support in KDE 4.2’s KPilot is: Calendar conduit (syncs against Akonadi), Contacts conduit (syncs against Akonadi), Memofile conduit (syncs to a directory/files on your hard drive), the Time conduit, the Palm database install conduit, and the ToDo conduit (syncs against Akonadi). These are by far the biggest heavy hitters (the 4 main Palm apps), but again, if you absolutely must have one of the others (or a new conduit altogether), please help us make it a reality by contributing.

Our little First Time Setup Wizard’s device detection functionality is broken.  Actually, it’s been broken for a while. But we didn’t have time to try to get it working, so we disabled that functionality. Really, this is ONLY a one-time setup issue, and there are far better ways to figure out what connection string you should be using, and they’re pretty standard now (“/dev/ttyUSB1″ if you’re using the visor kernel module, “usb:” for libusb syncing, /dev/ttyS* for serial devices, etc.).

Previously, KPilot tried to be a “anything that has to do with a Palm device” solution, and we had built-in viewers and editors for Palm databases. These were buggy and error-prone, and confusing, since it looked like KPilot could sync with your Palm, KDE PIM apps, and any changes you made to the databases through the viewers/editors. Well, no more. We’ve removed these viewers and editors to fix a bunch of bugs, to cut down on the porting and maintenance efforts, and to provide a cleaner user interface. KPilot is now focused on being a syncing solution between your Palm and KDE’s PIM back ends. If you need a generic palm database viewer/editor solution, JPilot is much-better suited to that.

Unfortunately, using “usb:” (libusb) to sync your USB palm still has some weirdness to it. I have not had time to dig until I found the solution, but even though we do the exact same thing with “usb:” devices through pilot-link that we do with old-style USB devices (/dev/ttyUSB1, etc.), we periodically hit a crash when closing libusb sockets. Sometimes this shows up as a double-free bug down inside libusb, and sometimes there’s other weirdness. Bottom line is this: “usb:” should be fine for syncing your Palm with KPilot, but you may see crashes after your data has been synced or when KPilot closes the socket handles to libusb (pi_close, in paricular, causes this). This is an area I’d REALLY like some help with, since I don’t see anything that KPilot is doing wrong.

One of the challenges we’ve always had is in getting our users to help us understand what’s going wrong when something goes wrong. In the past, this has meant that we’ve had to tell them to get KPilot’s source code, reconfigure it to make sure debugging is turned on, recompile, re-install, and test again before we could get ANY useful information for as to what might be going wrong. This presented an insurmountable barrier to entry for 99% of our users and has resulted in a lot of bugs never getting fixed and a lot of frustration and wasted time, all around. Well, no more. In KDE 4.2, KPilot now should have debugging (with tunable output levels) turned on by default. The positive to this is that we should be able to ask our users to just run their already-installed version of “kpilotDaemon –debug=9″ and send us the output for us to be able to get a much better look at what might be going wrong inside the wee beastie. The down-side is that we will be producing more console spew as a result. I’ve tried to keep this to a minimum, but I’m sure this will upset some people anyway. For those folks: workaround would be to run “kpilotDaemon >/dev/null 2>&1″. We can definitely improve in this area and prune down what gets printed by the default debug level, and I’d greatly appreciate any patches to help do so.

And lastly, as I mentioned previously, we made some intentional design decisions that favored the protection of our users’ data first and foremost. As a result, some things will take longer in KDE 4.2’s KPilot than they used to in KDE3. Most notably in this area is our “first sync”, where we take in both collections of data (Palm and PC) and match them up and result in a combined set. This area has not been performance-tuned (we’re currently at an operational efficiency of O(n^2) in our data matching code, I believe, which is obviously bad), and there are definitely things we need to improve on (and would REALLY appreciate the community’s help on!!!). If you have a database with thousands of records, then “first sync” (which happens obviously the first time, but also if the record mappings are invalid) will take a while and your Palm may time out. Less than optimal? Yes. Slower? Maybe, the first time. You lose data? Definitely not. Can you help make it better? YES! =:)

So, in closing, I hope this helps to get all you Palm users excited about our new version of KPilot. Never before has KPilot looked so good, been as careful with your data, or been easier to help debug, extend, and help out with. There will be some challenges, as there are with any new major version of software (and this is a doozie, all around!!!). But I’m really pleased with what we have and where we can go from here.

Thanks, enjoy, and please give us feedback!! As always, bugs should be reported to bugs.kde.org, e-mails should be sent to kdepim-users@kde.org, and more-or-less real-time help can be found in #kpilot on FreeNode IRC.=:)

Monday January 19, 2009
by Jason 'vanRijn' Kasper
0 comments

KPilot 4.2 Progress (woot!)

I spent a crapload of time this weekend, going through all the old and crufty KPilot bugs we’ve done a really horrible job of keeping up-to-date on, and triaged the bejeebers out of the list. I think we had ~ 150+ a few months ago. I went through the last 100 of them individually today, and was able to close out 93 of them, woot! A lot of them were problems that had been fixed in KDE 3.5.x, or had been directly addressed  more recently in our KDE 4.2 work, or had been indirectly fixed via our KDE 4.2 work. A lot of them were also the low-hanging fruit you’d expect with “it don’t work so good” and not much more to go on. But all told, we now have a very clean KPilot bugzilla bucket, with 12 open bugs (of which, 10 are wishlist items). We’re all set for the next onslaught of bugs from the upcoming KDE 4.2 release. =;D

I also did some more sync testing with KPilot today and am quite pleased with the results. Thanks to Bertjan’s excellent GSOC work from the last 2 years, we have a really solid syncing solution, and my confidence in it is only growing stronger, the more testing that I do.

So, with this little memento, and a renewed resolve to not be jealous of all the Camp KDE folks enjoying Jamaica whilst I spent 3 hours, shoveling snow today, I now turn in for the night.

KPilot Bug Fixing Mayhem!

Tuesday January 13, 2009
by Jason 'vanRijn' Kasper
6 Comments

KPilot 4.2 progress

I discovered a nasty little data corruption bug in KPilot last night and have put some fixes in for it just this morning. The good news is that we didn’t lose any data. We just gave you a lot more data. =:) So, if you’re helping to test KPilot for our KDE 4.2 release looming Any Day Now (TM), please update from svn (branches/KDE/4.2/kdepim/kpilot) and test again. There is still one little nasty behavior that I see that I need to find a fix for tonight, though. With our new core conduit design for KDE 4.2, KPilot keeps its Handheld -> PC mappings in its own XML file–one per conduit. This is a Really Good Thing (also TM). However, it seems that we don’t do a 100% perfect job just yet in being rigorous about validating this XML mapping file and when it gets messed up, bad things can happen. So, if you’re hitting weird problems with KPilot from KDE 4.2, try removing the XML mapping file for that particular conduit in ~/.kde/share/apps/kpilot/conduits/<PalmUserName>/mapping and re-syncing. That will force KPilot to do a “first sync” and re-create this mapping from both data sources. I’m not saying that’s a good answer, and I’m going to look at finding a solution for the real problem tonight, but it may come in handy for someone out there who’s seeing weirdness.

Saturday January 10, 2009
by Jason 'vanRijn' Kasper
13 Comments

Random Musings About a Good Week

It’s been a while since I’ve blogged (I blame Twitter), and I had an interesting week, this last, so I figured I’d blog about it. Probably should be a bunch of individual posts, but blef and here goes….

Yesterday was an awesome end to an otherwise already pretty good week. I got to play Tetrinet with my team at work and while this may not seem like a big deal, it was to me. Being that I’m currently working remotely, it’s very easy to feel isolated and alone and disconnected most of the time. Until I figure out how to build a virtual presence robot (like Twiki, maybe, except instead of  Dr. Theopolis hanging around his neck, it would be a webcam of me?!?), I don’t get many opportunities to feel a part of my team and get the kind of feedback that you normally get in a job by seeing how people react to you just by being around them. But anyway, it was a WHOLE lot of fun. I had never heard of, much less played, Tetrinet before yesterday, and I got my butt kicked soundly. But the camaraderie and laughter and fun was exactly what I needed.

On Tuesday, I got to spend the whole day in my dining room with a friend and co-worker from VMware and got some really cool Linux work done. It was actually some really sweet stuff that he did earlier in the year as part of his internship, but part of it got backed out due to Windows build issues. We worked through all of the issues (and found a couple of problems in GlibMM along the way) and he brought me up to speed with the features and implementation details and we did a pretty good job at documenting it all to boot. I can’t say exactly what it is, just yet, but if you’re a fan of VMware’s Unity mode (guest VM windows showing up inside your host, like normal windows instead of being contained inside the guest OS window), this work will make things just that much cooler. I’m working on Unity stuff for our next Workstation and Player releases and I’m hoping we get to include this coolness!

I’ve been using the Logitech VX Revolution Cordless Laser Mouse for a couple of years now and it is extremely cool. The neatest thing about it (other than the fact that it works perfectly in Linux and has a gazillion buttons, and the little storage compartment inside the mouse for the USB dongle) is the scroll wheel. They call it a “hyper-fast scroll wheel” and it is just that–you give it a good flick and it keeps going and going and going… awesome fun and really useful for long documents/web pages. But last week, I saw the Logitech Optical Marble Mouse and after reading all the reviews and talking to a friend who had 5 of them and loved them, I decided to give it a try, and I absolutely love it. It has the same kind of scrolling awesomeness as the VX Revolution wherein you flick it with your fingers and it keeps going much longer than a normal mouse wheel (albeit not nearly as long as the VX), but it also keeps your hand stationary to help prevent or improve RSI problems. It took just a few hours to get used to it after having used a normal rodent for decades, and it is now my favorite mouse. But it does take a little bit of configuring…

Silly me, but I am so used to having to hack things to do my bidding in Linux that I wasted a bunch of hours researching how to get the Marble Mouse to do horizontal and vertical scrolling. You see, the mouse only has 4 buttons, and no scroll wheel, so you use X’s EmulateWheel option and then tell it which mouse button to use (EmulateWheelButton) so that when you hold that button down and move your mouse, instead of moving the mouse cursor, it scrolls in that direction. REALLY cool! It seems, however, that the particulars of how to configure this mouse in X changes with each vesion of X, or at least between distributions. BUT, if you’re using OpenSUSE 11.1 as I am, just use YaST and change one of your mouse definitions to be the “Logitech TrackMan Marble FX (PS/2)” (even though you’re connecting it through USB), and you’ll find that it works beautifully (DOH! Should have tried that first!!!). I set my EmulateWheelButton to “8”, which is the little button on the left side of the mouse. I’m LOVING it! BTW, if you’re using Ubuntu Intrepid, there’s a drastically different way to get this working involving either HAL fdi files or a simple xinput script. Anyway, if you find yourself using this mouse and getting stuck on how to get it to scroll, add a comment to this post and I’ll provide more details.

I also got a chance to spend some time on Ye Olde KPilot this week, which felt really good. Truth be told, it’s darned necessary and scary, since KDE 4.2 is nearing release any day now. But I fixed a bunch of KPilot issues (layout, configure dialog, crashes, sync problems) and even got KPilot to successfully sync my calendar and contacts once. I need to spend some more time this weekend in trying out different sync scenarios to make sure we’re rock solid before the release, but the good news is that contrary to previous versions of KPilot, we’ve tried extra-special-hard to not lose your data. You may find that (right now), we err on the side of giving you  more data than less, meaning possible duplicates until we get those bugs fixed. So, right now would be a really good time for all you KPilot users (both of them?) to come on out and help us test KPilot. We have about a week to find and fix any problems. =:/ Oh, and I also went through the open Ubuntu KPilot bugs and triaged them a bit too, which felt good.

Along those lines, I actually did get a chance to talk to a couple of KPilot users this week (both of them, I think!!) and look through some problems they were having. I spent a large chunk of time looking into a bizarre problem a Kubuntu KPilot user was having from the Kubuntu 4.2 beta2 packages. Along the way, I learned how to find the kde_plugin_version in one of our .so’s (“gdb foo.so” and then “p kde_plugin_version”), and I added some debugging that should have been there all along anyway in KPilot, so it’s not all bad. But it turns out that the Ubuntu KPilot package is missing libkpilot_akonadibase.so, and so none of the new conduits work. I’ve discussed things with Jonathon Thomas on the Ubuntu bug page and this should be fixed for the next Ubuntu KPilot packages.

Before I started testing KPilot, though, I needed to get my PIM data in order. I’ve been meaning to put my contacts and calendar into Google for a while now, and this was the perfect time to do that. So I found this neat LifeHacker page about using Dropbox and KeePass for synchronizing all your private and important information, and cleaned up my contact information and put everything that could be considered sensitive or important into KeePassX, which is REALLY nice, and I highly recommend it. Excellent functionality, good strong encryption, and a beautiful Qt4 GUI to boot. I’ve not looked into using Dropbox yet, but that’s just an added benefit. After that, it was a simple matter of wasting 3 hours trying to format my kaddressbook-exported-to-csv file into something that Google likes, pulling my hair out, finally giving up in frustration, saving my std.vcf file to a shared drive, opening it up with OS X, importing it into the Mac address book, and then using A to G to create a CSV file and then importing that into Gmail’s contacts. *sigh* What a pain in the butt!! Someone seriously needs to write a Python script for this or something. Honestly.

I also discovered, much to my chagrin, that Firefox and Konqueror both consume ungodly amounts of memory with a 16-meg web page (to the point of exhausting all of my real and virtual memory and crashing X), like the error page I was getting from our internal sandbox compile machine, but Opera handles it beautifully. So I’m using Opera again, quite happily. Oh, and since Google now allows you to customize your Gmail keybindings, I can finally get around the annoyance of “#” not working for “delete”!! I’ve set up “d” for “delete” and now my Opera/Gmail experience is glorious again. Now, if we could just get THEMES in Google Apps For Your Domain, that would be AWESOME!

And in closing, the latest Street Fighter IV videos from shoryuken.com look amazing! I’m going to have to go to GameStop today and plunk down my pre-order money.

Monday December 22, 2008
by Jason 'vanRijn' Kasper
10 Comments

OpenSUSE 11.1 and nVidia == AWESOME!!

Stark contrast to my last post, I know, but I felt it was only fair to blog about the wonders of OpenSUSE 11.1, even/especially with my little nVidia chip. First off, I still think there’s something wonky going on with X and/or nVidia’s driver in taking so long to start that kdm ends up giving up and committing hari kari, but my little workaround in extending ServerAttempts and ServerTimeout in kdmrc seems to be at least good enough to keep me from committing hari kari myself. And quite honestly, that’s about as much time as I want to spend on debugging it. =:/

But I updated to the KDE 4.2 beta2 packages again today and am absolutely loving OpenSUSE 11.1. Things are blazingly fast and well-put-together, and best of all, my faith is totally restored in OpenSUSE after I reinstalled from scratch again. So what changed between my last post and now? A few things:

Yesterday when I installed the KDE 4.2 beta2 packages, I also pulled in the unstable Qt45 packages as well. Maybe that caused some harm? *shrug* All I know is today, I didn’t do that and I’m not seeing any problems.

I think I was using my old xorg.conf file (that worked perfectly well in OpenSUSE 11.0, mind you) yesterday, which still had a bunch of tweaks that I added over the last year to get nVidia to play nicely with KDE4. Today, I am just using the default xorg.conf, as written by sax2, and things are REALLY fast and stable. And based on a few comments I’ve seen (hi jospoortvliet!), it’s very likely that this is the true cause of my problems from yesterday. Here’s what my old Screen stanza looked like. Does anyone know exactly which one of these might be causing nVidia to hurl its little guts out in OpenSUSE 11.1 with xorg 7.4?

Section “Screen”
Identifier     “Screen0″
Device         “Device0″
Monitor        “Monitor0″
DefaultDepth    24
Option         “RenderAccel” “True”
Option         “UseEdidFreqs” “False”
Option         “TwinView” “1”
Option         “TwinViewXineramaInfoOrder” “DFP, CRT”
Option         “AddARGBGLXVisuals” “True”
Option         “DisableGLXRootClipping” “True”
Option         “DamageEvents” “True”
Option         “TripleBuffer” “True”
Option         “UseEvents” “True”
Option         “FlatPanelProperties” “DFP: Scaling = Centered; CRT: Scaling = Centered, Dithering = Enabled”
Option         “OnDemandVBlankInterrupts” “True”
Option         “PixmapCacheSize” “2000000”
Option         “AllowSHMPixmaps” “False”
Option         “BackingStore” “True”
Option         “metamodes” “CRT: 1680×1050 +0+0, DFP: 1680×1050 +0+0″
SubSection     “Display”
Depth       24
EndSubSection
EndSection

So, in addition to things being extremely awesome in general in OpenSUSE 11.1, I am totally thrilled to finally be able to use powerdevil (it is REALLY nice!!!), and really happy to finally have working hotplug/usb-drive mounting working in KDE 4.2!!!! (it failed hard in OpenSUSE 11.0 due to some hal permissions problems that I never figured out), and zypper (package management) seems to be even faster in OpenSUSE 11.1. And these are just a few of the things that I’ve noticed in the last couple of hours of X not crashing. =;)

And, of course, KDE 4.2 is continuing to to shape up and look, feel, and perform absolutely marvelously, and OpenSUSE 11.1’s beta2 packages are a great way of testing it out.

As for me, I’m just thankful to have a functional laptop again and I hope to get some good KPilot testing and bug squashing done during the next few days of Christmas vacation.

Merry <almost> Christmas, all, and to the OpenSUSE 11.1 guys, a huge thanks again for the awesome new distro. You guys just plain rock! =:)

Monday December 22, 2008
by Jason 'vanRijn' Kasper
23 Comments

OpenSUSE 11.1 and nVidia?

So, first off, OpenSUSE 11.1 has to be the sweetest, best put together distro, like ever. Really amazing, quality stuff.  The new installer has some excellent improvements, and package management has never felt zippier (zyppier??) However, there are a few problems that I’ve hit that I’m still trying to figure out after 2 days of fun and frolic.

First off, I have a laptop (meaning I cant change the video card) with an nVidia chipset (meaning I’d like to change the video card). So while OpenSUSE 11.1 works really nicely with the open source “nv” video driver, it can’t do any compositing, 3d, OpenGL, etc., etc. (meaning no wobbley windows or cube goodness or translucency or… you get the idea…).  So I followed these nice little 1-click instructions and installed the latest stable nVidia drivers, rebooted, and up came X with nVidia’s drivers quite nicely. So far so good. And then I clicked “logout”. And that’s where things started to fall apart. It looks like what’s happening is that nVidia’s X driver gets killed when logging out and trying to log back in again. I poked around a bit and saw in a log somewhere that kdm was timing out waiting for X and ended up giving up. So I bumped up some values in /usr/share/kde4/config/kdm/kdmrc in the “X-:*-Core” section (Core config for local displays). I changed ServerAttempts to 5 and ServerTimeout to 45, and it seems to help. Mind you, the underlying problem is still there, and X takes a LOOOOONG time to restart with the nVidia drivers, but at least this keeps kdm from failing altogether and me from getting stuck without an X session and an unusable console display (when this happens, and I’ve booted with the default vga= line, the console is totally unusable).

Secondly, one of the main reasons for my sticking with OpenSUSE is its exceptional support for KDE 4.2/trunk packages. So I installed a bunch of stuff from the KDE:KDE4:UNSTABLE:Desktop repository and discovered that X crashes far too randomly and regularly. This, combined with the above problem of X being unable to restart, using the nVidia drivers, made for a lot of ugliness. I reinstalled once already and am a little leery of bringing in the unstable 4.2/trunk packages. And yes, I’m aware that I’m trying to use something labelled quite clearly as “UNSTABLE”, but I’ve been using OpenSUSE’s excellent “UNSTABLE” KDE 4.2/trunk packages for 6+ months now without any problems whatsoever. And it’s been with the same version of the nVidia driver as I am now using. So… it must be something in the new versions of the kernel or xorg packages that’s causing problems? Is anyone else seeing this other than this guy (who never got his questions answered)?

Anyway, I’m going to spend another few days trying to iron things out. If anyone “out there” has any helpful hints or suggestions, I’d really appreciate them via comment. And, yeah, once I figure out what’s going wrong, I’ll look into filing bugs for this stuff…