Gaim Not so Fun
A while back, I was interested in hacking on Gaim. I didn't end up doing all that much: I resurrected one of the plugins from the dead, and messed around a bit, but other things (like saving myself from almost failing out of college) got in the way. The one thing I remember is that I never really liked hanging out in #gaim on Freenode. Some of the developers and "crazy patch writers", were, in my limited experience, arrogant assholes (not saying that I don't get that way sometimes, but this was chronic). At the time I was somewhat new to the OSS scene: I had been using OSS for a few years, but I hadn't really gotten too involved in the development side of things, so I didn't think too much of it: maybe that's just how things were "supposed" to be.
And so I stopped hanging out in #gaim. Time passed, and I found an awesome community of OSS developers who were welcoming and friendly, and just thrilled to have extra help. More time passed, and, though I rarely thought about it, I still had a pretty dim view of the Gaim developers.
Today I head over to Planet GNOME, and stumble upon this, and also this. And suddenly I feel validated. It's really sad: Gaim is a very high-profile OSS project, and it's a shame to see that the people behind it can't handle playing nice with each other. And now, with Sean Egan (Gaim lead developer) hired by Google, it seems like Google pretty much owns Gaim. I can certainly understand the lure of a good job with a company like Google, but it looks like a pretty crappy situation.
Ah well. The OSS world tends to route around stupidities. If enough people think Gaim needs to fork, it'll happen. If enough people think we need a new, better-designed IM client, it'll happen. If the current situation works itself out positively, all the better. Only time will tell.
Tablettage
So I finally ordered my Nokia 770 Internet Tablet, with the sweet developer discount. I was a bit afraid I'd been left out when I saw a bunch of other people ordering and receiving theirs. I guess they were just giving out the coupon codes in batches or something.
Anyway, it looks like a really cool device, and I'm looking forward to hacking on it. I was poking around the API documentation for the platform, and it seems like there's a lot to mess around with. The little guy has quite a bit of potential. I've been looking for the chance to cut my teeth on programming for an embedded device, and this looks like the perfect opportunity.
Annoyingly, the only shipping methods were fedex 2nd day, and overnight, and the 2nd day is $15. Lame. And of course that means it'll arrive nice and quickly... and then sit at my rental office for 5 days until I get back from Germany. Figures.
Wizards
Hmm, according to this, I'm a "wizard" at programming. Somehow methinks this dude overestimates the skill required to work with multithreaded apps. I think I'm pretty damned good, but I don't think I'd call myself a wizard. (Not to mention that that'd be pretty presumptuous.)
I also disagree with several of the statements in those slides as to why events are easier to handle than threads. For starters, I'll say that I do agree that locking isn't easy. In more complex cases, it's easy to forget a lock somewhere and get corrupted data, or to mis-design a situation where you can get deadlocks.
However, the statement "with threads, even the simplest application faces the full complexity" is a bit disingenuous. There are several tools available for communication between threads (such as locking queues) that allow a programmer to avoid nasty locking situations. Are they suitable for all situations? No, of course not. But sometimes, with a simpler multithreaded application, you can get away with ignoring mutexes, semaphores, condition variables, etc., depending on how the application works with its data -- or rather, how the application needs to share its data between different threads. Sometimes all that is necessary is to have a single data structure that holds "aggregate" data provided by multiple threads, and in that case all you need is a single mutex to protect that data structure. Sure, there are more complicated examples, but that's just my point: there are varying levels of complexity in multithreaded applications.
I'm also not seeing how the event-driven model is all that easy. It usually requires thinking about your program flow in a completely different manner than if you're using threads. Event-driven apps require asynchronous callbacks, and often a complicated state machine.
A great example of this stems from my work on my mail watcher plugin for the Xfce panel. The original mail checker had a terrible flaw: all network I/O was done synchronously, so any network delays would cause the whole panel to become unresponsive. I considered both solutions to this problem:
Using an event-driven model, single-threaded, with non-blocking network sockets
Using a multithreaded design, one thread per connection, with blocking sockets
Ultimately, I chose the second option. This way, I could have this program flow on checking for new messages:
Convert the server's hostname into an IP address.
Connect to the server.
Do the initial handshaking with the server and authenticate.
Check for new messages.
Log off from the server and disconnect.
With a multithreaded system, I could do all of these in succession, without worrying about blocking. Either each step could complete in the blink of an eye, or it could take 30 seconds for each step. It doesn't matter.
With an event driven system, I'd have to have a state machine with a state for every single time I try to receive data from the network. That means one state each for steps #1 and #2, two to four states for #3, one or two states for each message folder in #4, and at least once state for #5.
I suppose that isn't so terrible, but consider that because of how the C library works, there's no way to make #1 non-blocking. Also, for secure SSL connections, I would probably have to use a more complex interface into the security library I was using to avoid blocking within the library.
So eventually I decided to use threads. In the end, I had a couple small locking problems, which were immediately apparent and not difficult to fix. I don't recall encountering any deadlock situations.
I guess it just really depends on how your mind works best...
Sony is LAME
Apparently, the Go.exe binary that comes with the same discs infected with the Sony rootkit is statically linked to LAME, and thus a GPL violation.
Wow. Sony – You’ve made my day.
Search Strings
So, according to my website stats, these fine search engine strings have been used (among others) in the month of October to find my site:
everything is gay
bastard
academia sucks
Not much terribly interesting for November, except maybe "xray apendicitis" [sic], which is rather odd.
I am amused.
Trojan Using Sony DRM Rootkit Spotted
Most interesting Slashdot response I’ve ever seen
Upcoming Travel
I'm doing a bit more travelling before the year ends.
This Saturday (12 Nov), I'm leaving for Berlin for an Intel thing. I'll be there until the next Saturday morning. I should hopefully have a fair amount of time to do some sightseeing, and I'll be able to see Jens and Moritz while I'm there. Awesome. Malte, from our Munich office should be joining me for a couple days, which will be cool.
In December, I'm going back to the east coast for Christmas and New Year's. Amazingly, I managed to get a free flight with all the miles I've racked up with United this past year. I really thought that entire time period would be blacked out, but I managed to get a flight out on the 24th, and one back on the 4th. Not ideal, but it's free, so I'll take it. I'll probably be up in NYC for a day or two around the 28th or 29th, so if you're in the area, drop me a line. Otherwise I'll be in MD.
Joe Blow can, well, blow me
Well said. This is basically what I want to tell people when they say "Linux needs this", or "OSS needs this", or "your application needs this" if I want more people/average users/my grandmother to be able to use it. The bottom line is: I don't care if these people use Linux. And I certainly don't want them using Linux if getting them to do so means being forced to make stability and security compromises (among other things).