SPAM!
This has to be the funniest spam I've read in a while:
Hello, I am David Smith for Dailywillsupplies.We would like to buy computer accessories.Please can we have Pentium P4 3.0 775 pins computer processor?Or can you please tell us the brand of processors you have in stock and the price per unit of product.We are interested in buying in large quantity of 50 pcs,would like to have the quote for this product and also like to know the best form of payment for this transaction.We await your reply. Thank you. David SMith.
Interestingly, it was sent to my @ece.cornell.edu address, which I haven't used for anything in over two years. I'm actually surprised it's still active. I guess they forgot I left.
nVIDIA Hateage
nVIDIA has released the first driver in the 8xxx series for their video chipsets. The release notes look pretty sparse for a major build number jump. I was told that the issue with X eating 100% CPU would be fixed in this release, but it looks like it isn't. I'm getting the same "Xid" messages in syslog, along with "NV(0): WAIT (.....)" messages in the X server log which I don't believe had been appearing before. Unlike before, I can't save the X session by killing and restarting xfwm4; I have to bring the entire X process down remotely.
I've disabled window drop shadows for the time being to see if that helps solve the problem. Update: It doesn't.
I'm really getting sick and tired of this. nVIDIA appears incapable of releasing a stable driver set. I understand that X.org 7.0 hasn't been released yet, and Composite is new and experimental, but many other chipsets (such as the ATI Radeon Mobility 7500 in my laptop) work nice and stably with Composite and Exa enabled in the 7.0 release candidate. Just another data point in the huge mess of reasons why OSS is better than closed-source proprietary shit. I tried the OSS nv driver earlier, but simply moving a translucent window across half the screen took about 5 seconds. Not pleasant. I tried nv's experimental Exa support, but it crashes the X server on startup. Oh well. If I knew more, I'd try to hack on it.
I'm seriously considering tossing this card and buying an ATI instead. At least they release partial specs so OSS devs can write accelerated 2D drivers, even if the 3D acceleration is still a bit of a mystery. If my little 4-year-old laptop can handle Composite, I'm sure a newer board can as well.
Alternatively, anybody know of a decent video chipset with stable OSS drivers with acceleration that can handle Composite, without breaking the bank?
Update: As ElAngelo points out, nvidia released a quick fix-up release to hopefully fix the problems I'm experiencing. So far so good. On a side note, with the old drivers, it seems that disabling fast writes and sideband addressing seems to help the problem quite a bit: I didn't get a lockup for a couple days, vs. the usual couple hours.
Of Warts and Hogs
Which Hogwarts house will you be sorted into?
Your in-depth results are: Ravenclaw - 12 Gryffindor - 11 Slytherin - 10 Hufflepuff - 8
I Love perl
Sleeping is lame! Instead, I added perl bindings for libxfce4panel to xfce4-perl. This means people can write plugins for the Xfce panel in perl. Yeah, I think it's pretty awesome too.
This is really my one accomplishment for the weekend, aside from getting an oil change for my car and buying groceries.
My Poor Overheating Computer
Ever since I added a fifth hard drive to my computer, along with a higher-end video card (some of those higher-end features of which I'm now actually using), my machine has been overheating a bit, to the point that it sometimes locks up while performing long compiles. Not fun.
I've had my current computer case (affectionately named UPOS, aka Ugly Piece Of Shit) for over six years now. Despite having been around computers for a long time before that, it was the first computer that I built, as all the ones I had played with previously had been machines my dad had brought home from work. Anyway, my dad and I didn't really know as much as we should have about building a computer, and our extensive research left out a rather important piece of the pie: the case. And so, we went for something relatively cheap, which, as it turns out, had terrible cooling and noise characteristics. To install a usable fan in the front of the case, we ended up cutting holes in the sheet metal and plastic bezel. Originally, I also "modded" the 5.25" drive bay bezel to hold a smaller fan in the drive bay. Eventually, after I added a second CD-RW drive, I had to remove the extra fan. At that point in time, I still only had one or two hard drives, so it wasn't a terribly big deal.
Now, I have five hard drives and a single DVD-RW drive, taking up all of the bays. The interior is rather cramped, and all but one of the PCI slots are filled. The power supply is also a larger model than the one in it before.
So, I bit the bullet today (it was tasty) and ordered a new Antec P180 case. It's pretty awesome. It has more drive bays than I currently need, and is constructed in such a way to deal with common thermal problems, and also to reduce noise levels. While I've gotten used to my relatively-noisy PC in my bedroom over the past 6 years, it'll be nice to reduce that a bit. I'm not totally thrilled with the front-panel cover, as I always feel like they're unnecessary and just get in the way, but I guess I really don't use the DVD drive often enough for it to be annoying. Since it's pretty heavy, I opted for the longest, cheapest shipping method, so unfortunately it probably won't be here for about a week and a half, but fortunately it'll be here before I leave for Maryland.
It belatedly occurs to me that I could have asked for this as a Christmas present and saved myself $150. Oh well.
Fun With Jogging
Fun things that happened during my jog tonight:
I forgot about left-turning cars and the green left arrow, and almost got run over. It's amazing how fast you can run when there are cars coming straight at you and they don't look like they're slowing down.
I saw a tall Asian dude walking down the sidewalk smoking a joint. Weird.
Rain
It's rainy and windy today, and not at all sunny. I know I joke a lot, but I really do miss the rain. It actually is pretty boring to have sunny, warm days all the time. Not that I want to move back to Ithaca or anything, but it would be nice to have some rainy days distributed evenly throughout the year out here in CA, rather than getting 2-3 months of almost nonstop rain. Ah well. Nobody's perfect, even mother nature.
Eight is Special
Update: A quick grep through the gaim sources for the current CVS head shows that gaim_add_eight() isn't actually used anywhere in the code (anymore, at least). Ah well.
Xfmedia Refactoring
I've finally started my huge Xfmedia refactoring project. The idea is to make it a lot more maintainable and modularised. I've been doing this in tiny pieces for many months now (XfmediaPlaylist, XfmediaVideoWindow), but I can't really go any further without ripping huge pieces of the codebase apart and stitching them back together the way I want everything to be. I realise it's been a couple months since I released 0.9.1, but it'll likely be a couple more months (at best) before 0.10.0. I think 0.9.1 is fairly stable and featureful. Unfortunately, 0.10.0 probably won't have many user-visible changes, but I expect the plugin interface will finally be stable, or at least in a state where I can promise backward-compatibility for future releases.
Anyway, here's an initial sketch of how my current thinking looks with regard to object structure:
XfmediaApplication: This is more of a meta-object, but it'll keep track of "global" data and handle starting up the app, as well as tearing it down. I haven't decided yet, but it eventually may make sense to allow XfmediaApplication to instantiate multiple xfmedia main windows in the same process, so you can have multiple copies of xfmedia running in the same process space. I'm not really sure what this means for plugin interaction yet, so this may never become a reality. I doubt 0.10.0 will have this ability, but maybe in a future version.
I'm a bit less certain about how the next two objects fit.
XfmediaPlayer will be a very thin layer on top of XfmediaXine. It will know how to play streams and handle usual playback operations, as well as interact with the GUI.
XfmediaMainWindow is a GtkWindow representing the controls/playlist window. It'll act as a container for the XfmediaPlaylist, and hold the time label, song/status label, and control buttons and slider.
I'm not sure if XfmediaPlayer should be the container for XfmediaMainWindow, or the reverse. On one hand, it makes sense for the window to contain the player, but I think I'd rather have the player as the super-object, which will hold the main window, and know that it should do some UI-related things when playback events occur. E.g., if a stream is started from the stop state, the play button in the UI should change to a pause button. There doesn't seem to be a great way to handle this case with the reverse relationship.
So I guess the object relationships should go like this:
XfmediaApplication
XfmediaPlayer
XfmediaXine XfmediaMainWindow
- XfmediaInfobar
- XfmediaPlaylist
- XfmediaPlaylistQueue
XfmediaVideoWindow
XfmediaTrayIcon (?)
There will be only one XfmediaApplication per process, and this can be considered as a pseudo-global. The various XfmediaPlugin objects (one per plugin) will live as sort of a peer to XfmediaPlayer, and can (obviously) control playback, and probably modify or interact with some parts of the UI. I'll have to be careful to compartmentalise this properly, as I'm sure there are parts of the UI plugins shouldn't be allowed to touch. Fortunately, the XfmediaPlugin object shouldn't have to change, aside from adding new object signals.
There are a few other things that are just floating around.
There's the settings system, which isn't an object at all: just a set of global functions that act on a global settings store. That's definitely a problem if I want multiple xfmedia instances in a single process, since, e.g., you might not want a systray icon for each instance, or you might not want each instance to be sticky on all workspaces. This is going to be a bit of a pain, because all the xfmedia_settings_get_*() calls have only one argument for convenience. Also, when xfmedia exits, which instance gets to write out the settings file? Only the first one? This sounds a bit messy. But supporting multiple settings files for each instance is pretty messy too.
The remote control interface isn't an object either, but it's probably ok (almost) as-is, since it knows how to operate on a specific "session" of xfmedia.
Next we have the keybindings system, which probably needs to be mostly redone. Fortunately it currently acts on a specific XfmediaMainwin instance (which will become XfmediaMainWindow), so it should be relatively easy to modify it to operate on an XfmediaPlayer, and thus be multi-instance-safe. However, all the keybindings are stored in the same file, so I'm not sure it's useful to have separate keybindings for each instance. Also, I'd rather use a standard GTK mechanism for doing keybindings, so I'll probably rethink this at some point (GtkAction?).
The mediamarks editor and menu are keyed to a particular mainwin instance, but, again, I'm not sure it makes sense to make this per-instance. There's only one mediamarks file, supporting more than one in a "smart" manner is pretty difficult, and if you look at them like bookmarks, a web browser doesn't have different bookmarks per window.
The tray icon is something I'm not sure about yet. Having multiple tray icons for each instance sounds a bit silly. I'm thinking about the possibility of a single tray icon being able to control all the instances of xfmedia in the same process. The problem with this approach kinda defeats the purpose of the tray icon: to offer a few simple features of xfmedia just a couple quick mouse clicks away. Increasing the complexity of the tray icon directly contradicts this. At some point I might move the tray icon into a plugin.
Next there's playlist-files.h, which is mainly a set of utility functions for reading and saving various playlist types. It mostly operates on a XfmediaPlaylist instance right now, which I think is fine. The playlist files don't need to know about the player engine at all; they just need to know the contents of the playlist (or just how to load stuff into it).
The "jump to file" box is a bit awkward right now. Originally it was a separate window, but now it's integrated into the XfmediaPlaylist widget. So it's in a separate file, somewhat kludged into playlist.c. This needs to be integrated properly (though it really does work fine as-is) for maintenance's sake.
The last piece is the equaliser window, which I never finished because xine handles EQ in a rather weird way, and I never figured it out well enough to make it work right. I might come back to this at some point, in which case it'll just be a child of XfmediaPlayer, and nobody else needs to know a thing about it, except perhaps how to show and hide it.
A final question is what to do about XfmediaXine: should plugins be able to interact with it directly. I'm thinking no. This allows me to support other playback engines in the future (which probably won't happen, but it's not wise to close the door on the possibility), and helps make sure I've abstracted player details into XfmediaPlayer properly.
So I guess that's about it. Comments? Questions? Not saying I'll listen, but I'm curious to know what people think...
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.