I'm sitting here having a really hard time figuring out whether I most dislike mosquitos or GNOME's screensaver and power management. All I want is: Standard screensaver/power management stuff: you know, pretty pictures and/or turn off the monitor after a certain amount of time. Allow me (user and/or script) to easily disable it, so that e.g. the screensaver doesn't come on in the middle of a video. Allow me (user and/or script) to easily enable the screensaver and/or power management instantly. Don't frickin' lock the screen!!!1!! Having found GNOME screensaver and power management completely incapable of doing the latter 3, even after installing and configuring Brightside, and digging through gconf-edit for the lock settings (hint: they're there but don't seem to work), I decided to resort to disabling them and using trusty old xset. Now, Brightside will try to use GNOME's power management and/or screensaver, so if you want to avoid locking as I do you have to bypass that by using custom actions. The custom action for instant DPMS standby is xset dpms force standby. The custom action for DPMS disable is xset -dpms and then when leaving that corner do xset dpms 600 1800 3600. xset, or some GNOME monster, has a bug where xset +dpms doesn't work. It appears to work, i.e. xset q reports that DPMS was enabled, but it doesn't actually come on unless you explicitly set them (or force standby mode). Now, you'll also want to run that same command at the beginning of your session, so what you probably want to do is script that (so you only have to change the timeouts in one place) and call that script from Brightside as well as put it in your session startup. Being paranoid as I am, I took gnome power management out of my session (couldn't find gnome-screensaver in the session—maybe it's launched by the power manager?). But just telling them to never come on, and bypassing them in Brightside, should be sufficient.

I'm neither a republican nor a democrat, and I like to refrain from delving into politics on my blog (except perhaps in the case that it's tech-related). I have indeed formed an opinion about the candidates, though I'm still pondering some of the issues and third parties. Get Fuzzy today just about sums it up. So while I'm talking politics I might as well enumerate the issues on my mind. Privacy and Freedom, particularly of the flavor that has being stripped from us like mad since 9/11. Airplane "security", the Patriot Act, terrorism in the name of fighting terrorism, etc. Nobody's talking about this, I'll have to research their records, but I'm guessing McCain at least will fail this test. Technology savvy, or at least technology humility. Technology plays a huge and increasing role in the world, the economy, and the lives of many of us (especially me). Lawmakers and presidents have shown an amazing inability to grasp what is possible and impossible with technology, let alone what is wise. Intelligence and Wisdom. Frankly, things are just complicated. No set of ideals, even the ones I hold, are going to work if blindly adhered to. Ideals must be guidelines, and in the end any public official has to make lots of judgement calls. I want someone who will weigh the issues, consider alternatives that fall outside his idealogy, and listen to the smart and wise (and often contradictory) people that he (hopefully) surrounds himself with. Be a good neighbor. The rest of the world pretty much hates us by now. I could care less if people hate us for irrational reasons, and don't believe we're in any sort of popularity contest, but I believe it's important to our economy, livelihood, and very existence to be a peaceable, approachable, respectable, intelligent country instead of a warring, arrogant, ignorant, laughing stock country. It's not entirely fair, but people do judge the whole lot of us by who we elect to be our leader. This also affects me directly, since I interact with people from other countries regularly. Fix the bits of the system that are broken, e.g. Change Congress. McCain likes to tout himself as a maverick and reformer, but I'm far from convinced. I doubt either candidate will take us very far here, but if this issue comes into play it will be part of my decision, and may influence my local selections more. The economy, the war(s) and foreign policy, health care, education, pronunciation of "nuclear", grandmas, babies, and world peace. In case you couldn't tell, McCain has already dug himself into a pit in my mind. I get a much clearer picture of where Obama stands, and sense more intelligence and willingness to ponder from him, although I don't necessarily agree with some of the policies on his platform. I think it's important to realize that we are voting for people not issues. We live in a republic, which means we elect people to take care of stuff for us. We want them to represent our interests and ideals, but I think it's more important to want them to have integrity and be smarter than most of us when it comes to solving the problems that they are asked to solve. Because of the wide spectrum of things that come to the table (technology, justice, foreign policy, etc.) we can't really expect to find one person really good at all of them. So we need to find a person that will surround himself with smart people and be able to discern good ideas from bad. In short, we're voting for a leader, not a set of policies or anti-policies for the next 4 years.

I've been known to knock autotools (autoconf and automake and friends), but let it not be forgotten that I have also been known to say that alternative pickings are pretty slim. Part of the problem with autotools is that it's easy to make an unmaintainable and unusable mess, and one that is essentially opaque to the uninitiated. But, on the other hand, it's equally easy to use autotools in a sane way which is just as easy or easier than writing makefiles and whatnot by hand. Once you get over the initial learning curve. That has been a big caveat. I've climbed that curve a few times and it goes in one ear and out the other. Well, a friend pointed out an excellent tutorial on autotools which demystifies autotools. It also makes a good reference for next week when you've forgotten everything. If you're writing code to distribute, you should consider using autotools (and doing so sanely), and this is a good starting point. But that's not the only reason to check it out. You may just be curious, or you may wish to learn how this works so you can contribute patches and bring sanity to your favorite project's build system. But whatever you do, never ever just copy someone else's autotools configuration into yours and apply "shotgun debugging" to shoehorn it into your project. That is the wrong approach and the primary cause of so many broken autotools setups.

I've updated my bread/sourdough PDF to reflect the recipe and methods I have settled on. The bread recipe didn't really change, though I adjusted a few minor details in wording, etc. The sourdough pancakes recipe is completely new—the one from Joe Pastry which is so much better than the one I came up with. The biscuit recipe is the old biscuit recipe from the old sourdough cards that my family got with our start. I don't know if that source has a name or author, but I do have scanned images at http://hans.fugal.net/sourdough/. The consensus of all who eat these biscuits is that they must be served at Thanksgiving dinner in Heaven.

So I recently got fed up with making the wrong amount of dough for the intended loaf pan. I did some looking and didn't really find a definitive guide for loaf pan sizes and bread recipes. But I did find an underlying mostly-unwritten consensus, which I will share with you now. A "standard" loaf here in the states is about 1lb and baked in a 8.5x4.5 pan. At Wal-Mart yesterday here in Las Cruces, there were no metal pans of this variety, some foil pans of the right size but labeled 2lb (2 lb of what? I have no idea), and pyrex pans of this size. (I have one of those and I don't like it, although this is my preferred loaf size to make). The most constant property of a standard loaf seems to be that it uses 3 cups of flour. This of course seems ludicrous when you consider that measuring flour by volume is ridiculously variable, but I suppose it gets you in the ballpark. For the record, that's approximately 15 oz of flour, i.e. just shy of 1 lb flour alone. In my experience this is the appropriate size loaf for this pan. An "oversized" loaf loaf is supposedly about 4 cups of flour (so about 20 oz). The pan is 10x5 or thereabouts. My jury is still out on this, but I find that a 2lb loaf actually fits better in my oversized pan. Maybe I just like lofty crests. So I'd go 5–6 cups flour (25–30 oz). Wal-Mart had several of these in metal, labeled loaf pan or meat loaf pan. My favorite pan is longer, about 4x12, and probably a tea loaf pan. This also makes 1.5–2lb. I found, surprisingly, that it takes about the same amount of dough as the oversized pan. (Note, I own none of the linked pans above, but my pans are similar in size. Those are more like my wishlist pans, with the exception of the last where I already have the perfect tea loaf pan) Now how do they compare in volume? Well assuming you want similar height (all these pans are roughly the same height), we can just compare the area. Standard pan is 38 square inches, oversized is 50 square inches, and tea pan is about 48 square inches. So the oversized loaf is 1.3 times as large as the standard loaf. Why then do I find 1.5 times as much dough even lacking? I don't know, this is a true mystery. I think it has to do with aesthetics and me wanting a higher crest for a wider loaf. Even more mysterious to me is the tea loaf, which is narrow, seeming to swallow the dough. But when we look at how it is fairly close to the same size as the oversized loaf, it makes sense. So there you go. How about a recipe for a standard loaf? Ok. 15 oz flour (abt 3 cups) 10 oz water (1.25 cup) 1 1/4 tsp salt 1/2 oz sourdough start

One of the oldest and most universally useful tools we have is gnuplot. It is also one of the least understood and most underutilized tools we have. I can hear you now. "What do I need gnuplot for? I don't make graphs." Well that's exactly the problem. Everyone who works with data should be making graphs, and lots of them. Do you write programs that manipulate data? You need gnuplot. Do you want to evaluate performance or traffic on your website? You need gnuplot. Do you want to impress your friends with cool graphs of the growth rates of yeast and bacteria in sourdough or your weight loss and percent body fat? You need gnuplot. I've been using gnuplot for years. I scraped up enough gnuplot skillz to make basic graphs and it has been invaluable. But I knew gnuplot could do more than I knew how to make it do, and whenever I tried to do something advanced it was only with great pain that I succeeded. Often I failed. Let's face it, gnuplot can be a bear to learn. Why? Well, mostly because of the documentation. Not that there isn't any, almost the contrary. There's a lot of documentation, but it's very much reference documentation. What the world has been lacking is a good introduction to gnuplot that isn't afraid to get nitty-gritty where it needs to, but doesn't just parrot the abundant but obscure documentation that's already out there. We no longer need to wait. The book is called Gnuplot in Action by Philipp Janert, and it is an absolutely fantastic book. Really, I can't say enough good about it. Janert walks the fine line between cheesy tutorial and dense reference with the skill of a circus acrobat. The writing is approachable, yet chock full of useful information. Nothing is rushed, but it doesn't plod. The text is sprinkled with beautiful graphs that expand your imagination and open your eyes to the possibilities of gnuplot. In chapter 2, "Essential Gnuplot", the impatient reader is given a whirlwind tour of gnuplot basics. After just 11 pages you will know everything you need to know for 90% of the graphs you will ever need to create. In fact, you'll know more than I knew when I began reading it—I learned a couple things that I kick myself for never having discovered on my own. Chapter 3 goes into more detail on dealing with data, and in that chapter I learned a ton. Several of the things I learned in this chapter have saved me numerous hours this semester alone. Chapter 4 picks up the remaining miscellany. In part 2, all those nagging questions of polish are addressed. This is where I used to spend the most time banging my head against the wall, searching, plodding through various newsgroup threads. "How do I get this or that to look just right?" These types of questions are hard to find answers to in search engines. Janert takes us by the hand and explains each and every question I've ever had and a few I hadn't yet dared to have. Truly beautiful graphs are now within my grasp. What's more, it no longer seems like an exercise in pain but a simple recipe for success. After Janert explains these techniques they seem plain as the nose on your face, yet he's not condescending. Part 3 dives into the deep dark secrets of gnuplot. 3D plots, color, multiplots, different coordinate systems, fitting, terminals, and a dozen other things you didn't even know that you didn't want to know. No doubt you'll skim this section the first time and come back to it when you need those dark magic tidbits. Part 4 is arguably the most important part of this book, or perhaps second after part 1. Part 4 is a crash course on graphical analysis. What kinds of graphs you can create, when you should and shouldn't use them, how not to lie with graphs (and how to pick out people lying with graphs), and most importantly, how to go from raw data that you don't understand to organized data that you do understand and have pretty graphs to demonstrate to boot. All with practical examples that you can tweak for your own use. Finally, there's a gnuplot reference in the appendix. This is a deluxe package and has everything you need to become a gnuplot guru. I am thrilled that this book is coming to dispel the darkness surrounding gnuplot. I really have no cons to speak of, other than the prerelease PDF I had access to had some minor problems—the sort of problem I would expect to be resolved in the final stages of editing. I don't have experience with other Manning books, but having seen prerelease versions of other books from other publishers I'd say the current copy is par for the course. I'm certain they'll fix those things up and have an outstanding PDF in the end. I recommend springing for the dead tree version though, as I expect the reference at the end of the book and the examples throughout will be more accessible next to your computer instead of on the screen. (You already use quite a bit of real estate running gnuplot and/or editing a gnuplot file and displaying graphs.)

So Apple added this Genius thing to iTunes recently. Not being the type to get excited about new iPod styles, it looks like the most interesting thing they could come up with this year. I gave it a try. I am not impressed. I think it's because I've been spoiled. 5 years ago I was using what I still consider to be the peak of intelligent listening software, IMMS. Genius isn't half as cool as IMMS was then, and while IMMS hasn't made any quantum leaps in coolness, quite a few rough edges have been rounded off in the meantime. I've been living in a sort of IMMS drought the past couple of years, since I switched to using a laptop primarily. Namely, an Apple laptop. This Genius release spurred me on to rectify that situation. If the best Apple could do was generate a 25-song playlist based on statistics gathered from other people the hopes of someone else hacking up an iTunes plugin to do IMMS or something like it dwindled to obscurity. The bane of IMMS is, ironically, its most compelling feature. IMMS is cool because you don't have to do anything. It pays attention to your listening habits, and analyzes the audio, and makes intelligent decisions for you when you turn on random. 4 years ago I would show up to work and be in a Depeche Mode mood, so I'd manually queue up a Depeche Mode song or two and the whole day I'd be treated to complementary music. If the occasional happy song slipped through, I just skipped it and IMMS took the hint. Don't underestimate the amazing wow factor of a computer apparently reading your mind. But this focus on simple non-obtrusive UI has been its biggest technical struggle. Media players are now a dime a dozen, and few of them have the plugin and UI sophistication to support IMMS' modus operandi. IMMS was developed originally as a plugin for XMMS and even then ugly workaround hacks were required. Then someone wrote a queue control patch for XMMS, and if you patched your XMMS you were in heaven. Oh, did I mention that still almost no other media players even have queue functionality, let alone let the plugins control the queue? Then when you consider the set of media players usable on OS X the situation gets laughable. Somewhere in the middle MPD came along. It fit my situation well because the speakers over on the desktop were a lot nicer than the ones in my laptop. But queues it has not and nobody seems to care. Von bravely came up with an IMMS hack for MPD, but it was too hacky for me—too much like the old XMMS days before the queue control patch (incidentally, queue control is part of XMMS proper now as of version 1.2.11). So I suffered along with manual or truly random music listening. Until now. Recently I looked into this again for the desktop, and I was delighted to discover that one of the many XMMS descendants has finally solved the XMMS bitrot without throwing the baby out with the bathwater. Audacious is as cool as XMMS ever was and as modern as your favorite modern player (unless you measure modern by klunky iTunes-like screen-wasting music browsers). What's more, the imms plugin for it is right there in the Ubuntu repository. Just apt-get install imms-audacious and enable the plugin and you're off and running. So I set it up and… didn't use it. As in, we rarely listen to music on the desktop because nobody really sits there for very long. So finally earlier this week I hammered out a simple remote control using Audacious' dbus interface. That's another post, once I knock off a few other TODO points. Feeling on a roll and feeling left out when at school, I decided to get an IMMS solution on my laptop, running OS X Leopard (10.5.4). I'll spare you the agonizing play-by-play and give you the shortest path to success: install Audacious and then IMMS. Actually the really shortest path is to install XMMS and then IMMS, because XMMS is in MacPorts. But it's the old version of XMMS without queue control, and doesn't have CoreAudio support (you have to use the JACK output plugin) so I don't recommend that. To install Audacious, install its dependencies (mostly using MacPorts), then build it and its plugins. Installing its dependencies is the hardest part because it's difficult to locate libmcs and libmowgli (they're not where the README says they are, and Google is less than helpful). I just ended up stealing the *.orig.tar.gz files from the Ubuntu packages (apt-get source -d libmcs1 libmowgli). There is one patch you need for the plugins. src/CoreAudio/audio.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) Index: audacious-plugins-1.5.1/src/CoreAudio/audio.c =================================================================== --- audacious-plugins-1.5.1.orig/src/CoreAudio/audio.c 2008-09-19 12:08:01.000000000 -0600 +++ audacious-plugins-1.5.1/src/CoreAudio/audio.c 2008-09-19 12:10:28.000000000 -0600 @@ -326,7 +326,12 @@ gint osx_get_output_time(void) { gint retval; - retval = output_time_offset + ((output_total * sample_size * 1000) / output.bps); + if (output.bps == 0) + { + printf("Avoiding divide by zero in osx_get_output_time()\n"); + retval = 0; + } else + retval = output_time_offset + ((output_total * sample_size * 1000) / output.bps); retval = (int)((float)retval / user_pitch); //printf("osx_get_output_time(): time is %d\n",retval); Next you need to install IMMS. This is a bit more involved, but should be straightforward with these patches. I'll put them here and talk about each in turn. First, a missing include for mkdir() immsd/immsd.cc | 1 + 1 file changed, 1 insertion(+) Index: imms-3.1.0-rc4/immsd/immsd.cc =================================================================== --- imms-3.1.0-rc4.orig/immsd/immsd.cc 2008-03-02 18:54:06.000000000 -0700 +++ imms-3.1.0-rc4/immsd/immsd.cc 2008-09-19 08:05:58.000000000 -0600 @@ -2,6 +2,7 @@ #include #include #include +#include #include #include Then, a workaround due to OS X not having an initstate_r() (which I incidentally couldn't find in the current Linux manpages on Ubuntu or Debian either). This patch may not apply cleanly by itself, you may need to apply your cognitive reasoning. configure.ac | 3 +++ immsconf.h | 3 +++ immsconf.h.in | 3 +++ immscore/immsutil.cc | 9 +++++++++ 4 files changed, 18 insertions(+) Index: imms-3.1.0-rc4/immscore/immsutil.cc =================================================================== --- imms-3.1.0-rc4.orig/immscore/immsutil.cc 2008-03-02 18:54:06.000000000 -0700 +++ imms-3.1.0-rc4/immscore/immsutil.cc 2008-09-19 08:13:29.000000000 -0600 @@ -27,6 +27,7 @@ int imms_random(int max) { int rand_num; static bool initialized = false; +#ifndef INITSTATE_BUG static struct random_data rand_data; static char rand_state[256]; if (!initialized) @@ -36,6 +37,14 @@ int imms_random(int max) initialized = true; } random_r(&rand_data, &rand_num); +#else + if (!initialized) + { + srandom(time(0)); + initialized = true; + } + rand_num = random(); +#endif double cof = rand_num / (RAND_MAX + 1.0); return (int)(max * cof); } Index: imms-3.1.0-rc4/configure.ac =================================================================== --- imms-3.1.0-rc4.orig/configure.ac 2008-03-02 18:54:06.000000000 -0700 +++ imms-3.1.0-rc4/configure.ac 2008-09-19 08:17:58.000000000 -0600 @@ -68,6 +68,9 @@ else AC_MSG_RESULT([yes]) fi +AC_DEFINE(INITSTATE_BUG,, [initstate_r is buggy]) + + AC_CHECK_LIB(z, compress,, [with_zlib=no]) AC_CHECK_HEADERS(zlib.h,, [with_zlib=no]) if test "$with_zlib" = "no"; then Index: imms-3.1.0-rc4/immsconf.h =================================================================== --- imms-3.1.0-rc4.orig/immsconf.h 2008-09-19 08:05:31.000000000 -0600 +++ imms-3.1.0-rc4/immsconf.h 2008-09-19 08:18:23.000000000 -0600 @@ -121,6 +121,9 @@ /* Define to 1 if you have the header file. */ #define HAVE_ZLIB_H 1 +/* initstate_r is buggy */ +#define INITSTATE_BUG /**/ + /* Define to the address where bug reports for this package should be sent. */ #define PACKAGE_BUGREPORT "mag@luminal.org" Index: imms-3.1.0-rc4/immsconf.h.in =================================================================== --- imms-3.1.0-rc4.orig/immsconf.h.in 2008-09-19 07:48:52.000000000 -0600 +++ imms-3.1.0-rc4/immsconf.h.in 2008-09-19 08:16:32.000000000 -0600 @@ -120,6 +120,9 @@ /* Define to 1 if you have the header file. */ #undef HAVE_ZLIB_H +/* initstate_r is buggy */ +#undef INITSTATE_BUG + /* Define to the address where bug reports for this package should be sent. */ #undef PACKAGE_BUGREPORT This patch is just so libpcre can be found build/Makefile | 1 + 1 file changed, 1 insertion(+) Index: imms-3.1.0-rc4/build/Makefile =================================================================== --- imms-3.1.0-rc4.orig/build/Makefile 2008-03-02 18:54:06.000000000 -0700 +++ imms-3.1.0-rc4/build/Makefile 2008-09-19 12:25:05.000000000 -0600 @@ -18,6 +18,7 @@ libimmscore.a: $(call objects,../immscor libmodel.a: $(call objects,../model) svm-similarity-data.o $(AR) $(ARFLAGS) $@ $(filter %.o,$^) +immstool-LIBS=`pcre-config --libs` immstool: immstool.o libmodel.a libimmscore.a training_data: training_data.o libmodel.a libimmscore.a train_model: train_model.o libmodel.a libimmscore.a Linking shared libraries on OS X is so much different from on Linux that there is almost always a need to do a patch something like this. rules.mk | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Index: imms-3.1.0-rc4/rules.mk =================================================================== --- imms-3.1.0-rc4.orig/rules.mk 2008-09-19 09:04:13.000000000 -0600 +++ imms-3.1.0-rc4/rules.mk 2008-09-19 12:25:50.000000000 -0600 @@ -14,9 +14,8 @@ link = $(CXX) $(filter-out %.a,$1) $(fil %.o: %.c; $(call compile, $(CC), $ + +#ifdef BMP +#include +#include +#include +#elif AUDACIOUS +#include +#include +#include +#endif +#include "immsconf.h" +#include "cplugin.h" + + +int use_xidle = 1; +int poll_tag = 0; + +GtkWidget *configure_win = NULL, *about_win = NULL, *xidle_button = NULL; + +gint poll_func(gpointer unused) +{ + imms_poll(); + return TRUE; +} + +void read_config(void) +{ + ConfigDb *cfgfile; + + if ((cfgfile = cfg_db_open()) != NULL) + { + cfg_db_get_int(cfgfile, "imms", "xidle", &use_xidle); + cfg_db_close(cfgfile); + } +} + +void init(void) +{ + imms_init(); + read_config(); + imms_setup(use_xidle); + poll_tag = gtk_timeout_add(200, poll_func, NULL); +} + +void cleanup(void) +{ + imms_cleanup(); + + if (poll_tag) + gtk_timeout_remove(poll_tag); + + poll_tag = 0; +} + +void configure_ok_cb(gpointer data) +{ + ConfigDb *cfgfile = cfg_db_open(); + + use_xidle = !!GTK_TOGGLE_BUTTON(xidle_button)->active; + + cfg_db_set_int(cfgfile, "imms", "xidle", use_xidle); + cfg_db_close(cfgfile); + + imms_setup(use_xidle); + gtk_widget_destroy(configure_win); +} + +#define ADD_CONFIG_CHECKBOX(pref, title, label, descr) \ + pref##_frame = gtk_frame_new(title); \ + gtk_box_pack_start(GTK_BOX(configure_vbox), pref##_frame, FALSE, FALSE, 0); \ + pref##_vbox = gtk_vbox_new(FALSE, 10); \ + gtk_container_set_border_width(GTK_CONTAINER(pref##_vbox), 5); \ + gtk_container_add(GTK_CONTAINER(pref##_frame), pref##_vbox); \ + \ + pref##_desc = gtk_label_new(label); \ + \ + gtk_label_set_line_wrap(GTK_LABEL(pref##_desc), TRUE); \ + gtk_label_set_justify(GTK_LABEL(pref##_desc), GTK_JUSTIFY_LEFT); \ + gtk_misc_set_alignment(GTK_MISC(pref##_desc), 0, 0.5); \ + gtk_box_pack_start(GTK_BOX(pref##_vbox), pref##_desc, FALSE, FALSE, 0); \ + gtk_widget_show(pref##_desc); \ + \ + pref##_hbox = gtk_hbox_new(FALSE, 5); \ + gtk_box_pack_start(GTK_BOX(pref##_vbox), pref##_hbox, FALSE, FALSE, 0); \ + \ + pref##_button = gtk_check_button_new_with_label(descr); \ + gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(pref##_button), use_##pref); \ + gtk_box_pack_start(GTK_BOX(pref##_hbox), pref##_button, FALSE, FALSE, 0); \ + \ + gtk_widget_show(pref##_frame); \ + gtk_widget_show(pref##_vbox); \ + gtk_widget_show(pref##_button); \ + gtk_widget_show(pref##_hbox); + +void configure(void) +{ + GtkWidget *configure_vbox; + GtkWidget *xidle_hbox, *xidle_vbox, *xidle_frame, *xidle_desc; + GtkWidget *configure_bbox, *configure_ok, *configure_cancel; + + if (configure_win) + return; + + read_config(); + + configure_win = gtk_window_new(GTK_WINDOW_TOPLEVEL); + gtk_signal_connect(GTK_OBJECT(configure_win), "destroy", + GTK_SIGNAL_FUNC(gtk_widget_destroyed), &configure_win); + gtk_window_set_title(GTK_WINDOW(configure_win), "IMMS Configuration"); + + gtk_container_set_border_width(GTK_CONTAINER(configure_win), 10); + + configure_vbox = gtk_vbox_new(FALSE, 10); + gtk_container_add(GTK_CONTAINER(configure_win), configure_vbox); + + ADD_CONFIG_CHECKBOX(xidle, "Idleness", +#ifdef BMP + "Disable this option if you use BEEP on a dedicated machine", +#elif AUDACIOUS + "Disable this option if you use Audacious on a dedicated machine", +#endif + "Use X idleness statistics"); + + /* Buttons */ + configure_bbox = gtk_hbutton_box_new(); + gtk_button_box_set_layout(GTK_BUTTON_BOX(configure_bbox), GTK_BUTTONBOX_END); + gtk_button_box_set_spacing(GTK_BUTTON_BOX(configure_bbox), 5); + gtk_box_pack_start(GTK_BOX(configure_vbox), configure_bbox, FALSE, FALSE, 0); + + configure_ok = gtk_button_new_with_label("Ok"); + gtk_signal_connect(GTK_OBJECT(configure_ok), "clicked", + GTK_SIGNAL_FUNC(configure_ok_cb), NULL); + GTK_WIDGET_SET_FLAGS(configure_ok, GTK_CAN_DEFAULT); + gtk_box_pack_start(GTK_BOX(configure_bbox), configure_ok, TRUE, TRUE, 0); + gtk_widget_show(configure_ok); + gtk_widget_grab_default(configure_ok); + + configure_cancel = gtk_button_new_with_label("Cancel"); + gtk_signal_connect_object(GTK_OBJECT(configure_cancel), "clicked", + GTK_SIGNAL_FUNC(gtk_widget_destroy), GTK_OBJECT(configure_win)); + GTK_WIDGET_SET_FLAGS(configure_cancel, GTK_CAN_DEFAULT); + gtk_box_pack_start(GTK_BOX(configure_bbox), configure_cancel, TRUE, TRUE, 0); + gtk_widget_show(configure_cancel); + gtk_widget_show(configure_bbox); + gtk_widget_show(configure_vbox); + gtk_widget_show(configure_win); +} + +void about(void) +{ + if (about_win) + return; + + about_win = +#ifdef AUDACIOUS + audacious_info_dialog( +#else + xmms_show_message( +#endif + "About IMMS", + PACKAGE_STRING "\n\n" + "Intelligent Multimedia Management System" "\n\n" + "IMMS is an intelligent playlist plug-in for BPM" "\n" + "that tracks your listening patterns" "\n" + "and dynamically adapts to your taste." "\n\n" + "It is incredibly unobtrusive and easy to use" "\n" + "as it requires no direct user interaction." "\n\n" + "For more information please visit" "\n" + "http://www.luminal.org/wiki/index.php/IMMS" "\n\n" + "Written by" "\n" + "Michael \"mag\" Grigoriev ", + "Dismiss", FALSE, NULL, NULL); + + gtk_signal_connect(GTK_OBJECT(about_win), "destroy", + GTK_SIGNAL_FUNC(gtk_widget_destroyed), &about_win); +} Index: imms-3.1.0-rc4/clients/audacious/rules.mk =================================================================== --- imms-3.1.0-rc4.orig/clients/audacious/rules.mk 2008-03-02 18:54:06.000000000 -0700 +++ imms-3.1.0-rc4/clients/audacious/rules.mk 2008-09-19 15:28:17.000000000 -0600 @@ -7,7 +7,7 @@ libaudaciousimms-LIBS = $(AUDACIOUSLDFLA audaciousinterface-CPPFLAGS=$(AUDACIOUSCPPFLAGS) audplugin-CPPFLAGS=$(AUDACIOUSCPPFLAGS) -audaciousinterface.o: bmpinterface.c +audaciousinterface.o: audaciousinterface.c $(call compile, $(CC), $

Steve Yegge has posted an funny, irreverent, and above all excellent argument for touch typing. I highly recommend it even if you do touch type. I am downright flabbergasted by some of the comments though. There are hunt-and-peck folks defending their inability to touch type as lifestyle choice based on the belief that they will get RSI. People justifying typing slow because it saves them from wasting time chatting or writing long emails. There are some interesting claims from 2–4 finger typists that they can type without looking at 70wpm (this is certainly possible), and choosing not to learn to touch type the "right way" because it will give them RSI (this is certainly ludicrous). Typing is a vital skill if you work in IT, especially programming. Of this there is no doubt, rationalizing strangers aside. I simply cannot imagine being stuck typing at 10wpm or less. It would be like being stuck behind a pair of tractors on the freeway going 20 mph. For the rest of your life. Last I checked I type about 65 wpm on average. I could probably go faster, but I never have felt the need. I can type as fast as I think when programming. If I were a stream-of-consciousness novelist or a secretary, I could probably make use of a faster typing speed. As it is, 60–70wpm seems to be a sweet spot for me. I'd like to discuss the ridiculous RSI claims. Yes, if you type all day without breaks you can get RSI. There are certain things you can do to mitigate or exacerbate this for a given amount of typing and typing speed. If you tried to go lightning fast all the time you might hasten the onset of RSI. But I argue that the absolute worst thing you can do if you're afraid of RSI is to not touch type. RSI means Repetitive Stress Injury, from repetitively performing certain motions until your body starts to break down. Smaller more relaxed motions are less stressful on your body than large stiff motions. If you touch type well, your hands are relaxed, your fingers float over the keys, and movement is minimal. Of course you still need to take care—take breaks, spend some time thinking without typing or drawing pictures on paper, proper nutrition, etc. But the biggest thing you can do to prevent RSI is to have proper form. And maybe learn dvorak (I still use qwerty because I find sysadmin and programming to be tedious with dvorak, but I don't spend most of my time actually typing). On the other hand, if you hunt and peck 24/7 guess how much more movement—repetitive movement—your body is enduring? Ever heard of tennis elbow? RSI isn't the exclusive privilege of touch typists. If you type slow enough that you can't possible get RSI, you are irrelevant. If you type fast enough to be productive but don't have good form, you are setting yourself up for RSI. If you're RSI-prone or just paranoid, go learn dvorak now or find a job that doesn't require much typing. I'd add to Steve's exhortation to learn to touch type, that if you do touch type but you feel your form is off, you have low accuracy, or you feel that your fingers are stiff, do some conscientious practice. Focus on accuracy and relaxation first, then speed. Enhancing your typing skills is a great benefit if you spend a lot of time typing, although learning to touch type in the first place is obviously a much bigger payoff. Let's continue to learn from musicians: correct form (including relaxed posture and keep those wrists off the keyboard/desk), accuracy, then speed.

A while back I posted about chiles rellenos. Now there's a video.

Here are the promised pictures of my Hipster Personal Analog Assistant:

I've been exploring D the language. I really do like it, but that's another post. There are a couple of D compilers, but the only viable option on OS X seems to be gdc. I installed it via MacPorts. On Leopard, gdc generates assembly that makes the FSF gcc complain "indirect jmp without `*'" over and over. The bug is known, and other than being annoying it seems harmless. So I decided what I needed was a script that would filter out these frivolous warnings without otherwise affecting stderr, and also without changing the exit status (so make can do the right thing). This turned out to be easier said than done. Finally I stumbled on the right incantation: #! /bin/bash gdc=/opt/local/bin/gdc msg="indirect jmp without" $gdc "$@" 2> >(grep -v "$msg" 1>&2) We redirect stderr to the named pipe corresponding to that subshell (see "Process Substitution" in the bash manpage), then we redirect grep's output to its stderr. Because grep is in a subshell, its exit status doesn't mess up the exit status of the script, which is the exit status of gdc, as it should be.

A friend of mine is struggling to grok the MVC pattern. I remember when I first tried to grok it how frustrating it was. There wasn't one final "a-ha" moment when I grokked it, but one day I looked back and realized I understood it. At that moment it dawned on me just how amazingly silly this whole process is. MVC is not some magical formula that if you implement it will endow your application with magical powers. It is a paradigm. A worldview of application programming. Once you get it, you realize that everything is MVC. It's just that some of it is cleaner MVC than others. The trick is in keeping the three components separate, but they're always there. My friend is still confused after an IM conversation, because his preconceptions about the computer and probably his desire to find that something different are getting in the way. So let's use a non-computer analogy. You've seen The Hitchhiker's Guide to the Galaxy, right? Of course you have. If not, I'll wait. Ok, remember the scene where Trillian is at a desk with a Vogon who asks her here home planet? She says it's Earth, the Vogon can't find Earth, she tells her where it is, she says it was destroyed, and does Trillian perhaps have another home planet? Yeah, I don't do it justice. Ok, so Trillian is the user. The Vogon is the controller, the computer is the database, and there are several views in play. The first view is the Vogon telling Trillian that it was destroyed. The second view is when she turns the computer monitor around so the incredulous Trillian can see for herself the video of the Earth being blown up. The third view is authorization with Zaphod's autograph. The nice thing about MVC, see, is that the model has no clue about the view or the controller. It just provides an interface for the controller to get and change the model's information. Likewise the view is pretty dumb. It accesses the model, or a snapshot thereof. But it doesn't make decisions. It just displays stuff. The controller is the "brains" behind the operation. It coordinates showing the user the correct view of the bit of the model that the user wants to see. It handles updating the model with new information. Ok, still confused? Let's try another. This time the controller is your CD player. The model is a CD. The view is your amplifier and speakers, or whatever else you have plugged into the audio outputs. An oscilloscope maybe? You the user push buttons and the controller changes the view. The model and view are obviously decoupled. But this analogy isn't perfect because the view isn't accessing the model directly, as is usually the case in MVC, but is being spoonfed the data by the controller. In my opinion this distinction is irrelevant, because the whole point is to achieve decoupling and whether the controller provides the decoupleable data or the view fetches it directly from the model is irrelevant to decoupleability, as we can see with this real-world example. Also this analogy might be better if we think back to cassette tapes which allow us to change the model (by recording), whereas the CD is read-only. Ok, so now let's bring it to the computer domain. The model is a database. Actually it's usually a wrapper around a database (which is in turn usually decoupled too), like ActiveRecord or your homegrown classes. You almost always write classes, because representing "stuff" is what OOP is good at. It doesn't have to be a real database of course, it could be just objects in RAM or a flat file. The key word for models is data. Now, the view is almost always entirely contained in the GUI toolkit you're using. The toolkit writers figured out all that boring stuff that lets you draw widgets and pack them together in a dialog box, etc. All that stuff you wouldn't want to do manually is the view. You may have some view code which deals with setting up the widgets, etc. The view may not even be visual—it might be a file on disk or sound coming out the speakers. The key word for views is render. The controller is everything else. Those GUI toolkits usually have some controller help too, since GUIs are interactive views and the events that the controller reacts to are coming from the view, in a sense. When you write callbacks, you're writing the controller. The controller figures out what to do in response to various events. It decides how to manipulate the views. It tells the views what data to display. The key word is event, and maybe coordination. So you see, if you're using a toolkit or framework you're already sort of doing MVC. The real litmus test can be boiled down to the following questions. If you can answer yes to all of them, then you're doing MVC. If not, you're not. Could I render different views without duplicating control code? Could I use my model code unchanged in a completely different application, and could I switch databases (if you have a persistent model) like I switch CDs? Is my model ignorant of the rest of the program? Do I feel like MVC is making my life easier, not harder? Have I sent chocolate to Hans recently? There you have it. I hope it was helpful.

I've talked about the Hipster PDA a few times. I finally stabilized on a system that works for me. I've been using it steadily for months with no major changes now, so I thought I'd share with you. My brief foray into the hipmod was fun, but too restrictive and small in the end. I understand others enjoy it though, so I'm glad I did it. I find the classic hipster with a few modifications works best. My biggest beef with the original hipster is that it falls apart and it's not very user-friendly. That binder clip had to go. So I got some binding rings (½" I think, but the exact size isn't critical) and use a standard 3-hole punch to punch 2 holes in the index cards, and bind it with 2 rings. This makes a more book-like planner, which nicely folds over on itself. Now, those rings can be pesky to open and close so I decided not to. I snip a little cut from the edge of the cards I want to be removeable to the holes. They stay in but will come right out and go right in without struggle. I also like to print some forms (as you've seen). These I just print on regular paper and trim to size with a guillotine then hole punch (no snips, that works best on cardstock). I made front and back covers out of a cereal box and duct tape, and even a pen holder out of duct tape. I'll post a picture soon so you can see. My planner consists of a few reference pages I printed out (including a circle of fifths, a few airport kneeboards, performance data for my favorite planes, and morse code… anything you can find a PDF for.), my weekly calendar/todo list pages, and a bunch of index cards that I use for notes, moments of inspiration, or whatever else they come in handy for. Oh, and a paperclip to mark the current week. I only have to reprint/refill the weekly pages about once every 3 months or so. For printing things, I wrote a script that automates some of what I mentioned in previous posts.

So I finally got around to trying out the "New FamilySearch" today. I am both impressed and disappointed. First the good parts. NFS (you didn't think I was going to type "New FamilySearch" over and over, did you?) has an impressive goal and paradigm. The goal is to create one hugemongous centralized database for all church members. The idea is to get away from the half dozen church databases (Ancestral File, IGI, etc.), and the half gazillion individual databases. A noble goal but a very scary one. It would be easy to screw this up and make a bigger mess than that with which we started. In fact this is why I have been reluctant to check it out—I didn't want to be disappointed and I wholly expected to be. Well, they actually pull it off quite well. The new paradigm is to keep everything and to promote recording evidence. In short, genealogy done right. When you merge a person, that is recorded and available for others to see. When you want to change information, you don't change it directly (as you would in a conclusion-based program like PAF), but instead you "add an opinion" complete with sources and/or notes. If you think that a piece of information is wrong and you have evidence against it, you can dispute it (again, giving source and notes). The old "wrong" information isn't eliminated, but it is marked as disputed. The changes and choices you make about people show up in the pedigree chart etc. This is multi-user genealogy done well (I might call it "distributed genealogy", but I'll reserve that term for something better, as you'll see later). From the perspective of an LDS member this is a fantastic system. When ordinances are performed in the temple they are immediately reflected in the database. When you want to do temple work for so-and-so, you state your intentions in the system and print out a page to take to the temple with you. If anyone else tried to do the same work, they'd see it was in process. This will drastically reduce—perhaps even essentially eliminate—duplicated effort in the temple. I have to say it's about time. It would have been cool 10 years ago. It was expected 7 years ago. Now it's finally here. There are some other cool tidbits, too, like the pedigree view which combines couples to make better use of space (are they the first to think of it? Probably not, though I haven't personally seen this approach before): There's an info box at the bottom with different tabs, one of which is "possible duplicates". I much much much prefer working with duplicates in this manner, rather than a global "match and merge". Very nice. There are also time lines and Google Maps integration (see where your ancestor was born, married, died, etc.). And those little temple icons unobtrusively notify you of potential temple work to do (or that has already been done). Overall they make nice use of AJAX, too. But there's problems. Big problems. It's slow. Painfully slow. It's slow enough to be a real pain for doing actual genealogical work. Maybe people with limited computer skills wouldn't find it slow, because it moves at about the pace they can keep up with. But for those of us in the computer age (read: almost everyone in my generation or younger) it is painful and restrictive. Why is it slow? Because it's a web app. News flash! Even AJAX web apps are slow. Ok, it's slow. No big deal, right? Just download the GEDCOM, do your research, and upload the changes. Right? I have news for you. There's no exporting data from NFS. The help center has this to say: Exporting Information from FamilySearch for Use in Your Personal Computer This topic describes how to get information from FamilySearch into your family history computer program. If you find information in FamilySearch that you do not have, you will need to either use the cut and paste features of your operating system or retype it into your computer program. Currently, FamilySearch does not support downloading information for use with Personal Ancestral File or similar computer programs. Family history computer programs may choose to support this feature when it becomes available from FamilySearch. Really. Cut and paste! It is a big black hole waiting to consume your information and display it to you on its terms only. Its slow terms. You want to make a family pedigree website? Write a script to spit out all the place names of your ancestors so you can put blue dots on a map? Make a Google Maps mashup? Do any number of other useful things with a GEDCOM export, including actually be able to work with it at a reasonable speed, put it on your handheld for reference at the family history library? Print out reports? No way. Uh-uh. Remember how I avoided using the term "distributed genealogy"? It's like having your genealogy in a distributed revision control system like mercurial or git, but you can only access the one single repository with a web interface. You can't check out the code. You can't work offline. You can't use your own tools. You can't write emergent scripts. You're screwed. For understandable reasons, you can't see information on living people, and they don't show up as search results. You do get access to your own ancestors and descendents and your spouse, but apparently not your spouse's family, your siblings, or any information on living people (like your parents' birthdays, etc.). You can enter this information in, or upload it in a GEDCOM. But the first rule of genealogy is start with your 4 generations. If everyone starts with their 4 generations, but most of those people are still alive, then how much effort is duplicated? How many duplicate versions of my dad will there be? Well let's see, he has 11 siblings, various aunts and uncles who are into genealogy, 7 children (who should all see the same record, but might conceivably enter conflicting information). Not a huge problem, but an annoyance. Once you fill out the tree to the dead people (hint: upload a GEDCOM of what you already have here, but only those first couple generations), then you find and link the dead people into the tree, then you have a nice resource. So far, it's just a research resource—I wouldn't trust a lot of things further than I can throw them, but they make good research jumping-off points. Maybe eventually through the hard work of thousands it will converge to a respectable database, in the spirit of a wiki. Also, it's presently restricted to LDS members (you need your membership number and confirmation date to register). The best genealogists I know aren't LDS. Certainly the bulk of decent genealogists I know aren't LDS. Most of the lousy genealogists I know are LDS. (Of course, that doesn't mean we have a monopoly on lousy genealogists, I just haven't had reason or opportunity to mingle with lousy non-LDS genealogists much). So this seems like a drawback across the board. Maybe down the road (I think it's still beta, though they never use that word) it will allow GEDCOM export and be available to all genealogists. Maybe the speed issue will be addressed, or they'll come up with a desktop client. Maybe this will be the rockingest genealogy database ever. Or maybe it will be of marginal interest—a great way to prepare names for the temple and avoid duplicate temple work, but not a good tool for daily genealogical work. Time will tell. I am impressed by the no-information-loss implementation. I'd like to propose taking it a step further. What if we could publish genealogical repositories on websites like we do with mercurial or git? What if we had the genealogical equivalent of github? What if you and all the other genealogists out there could, without information loss, match and merge and add information and correct information and unmerge faulty merges and… all without loss of information, the ability to go back in time (like you can with a revision control system), etc. A global genealogical database, a global record of genealogical discovery. Now, one huge database doesn't make a lot of sense. It'd be a pain to push and pull. So you'd have to be able to push and pull only pieces of the tree. And of course the merging, confidence, dispute, etc. aspects would have to be dealt with well (as they mostly are in NFS, though there would be unique challenges for it in a truly distributed genealogical system). Just imagine the potential. And feel free to expound on your imaginings in the comments.

My family is really into sourdough biscuits and sourdough pancakes. But to be honest, the recipes they use are a bit peculiar. You've probably never seen pancakes or biscuits like these, but you end up loving them anyway. I'm going to talk about the pancakes here and ignore the biscuits which are generally regarded to be the epitome of perfection by all who consume them. Here's the recipe they use for sourdough pancakes: Note that last bit: "approximately 80 small pancakes.… Remember that sourdough pancakes have a very firm texture, and are entirely different from the pancakes you are used to." They're small, white, rubbery, sour, and delicious. But you see, I'm really only interested in the sour and delicious parts. I have no investment in them being small, white, and rubbery. So when Joe Pastry (a food blogger I have immense respect for) started talking about sourdough pancakes, and showed pictures of normal brown pancakes that I'm sure were sour, delicious, and not rubbery, I had to try it out. And so I did, this morning. I followed his recipe, except I halved it (yes, I halved an egg) and made it with whole wheat flour (as he discusses at the end of the post). The pancakes were excellent. All the requisite sourdough taste and deliciousness, and normal pancake size/color/texture. Plus it was a lot of fun to watch the batter foam up when I added the soda water. So if you make small white rubbery sourdough pancakes (that means you, family), give his recipe a try and see if you don't like it even better. Then I recommend you read the follow-up post on the science behind sourdough pancakes. And for extra credit, compare the two recipes and hypothesize on why the results are so different.

So it's been awhile since I estimated my residual lung volume (RV), and I figured it was time to do it again. I'm a big guy, so my lungs hold a lot of air. When you're blowing all your air into containers in the bathtub, and you're ⅔ or more exhaled, is not the best time for pausing to move your straw to another container—or worse, refilling the container. This time I decided to use a balloon. I took a deep breath, exhaled maxmially into the balloon, then blew the rest into the container through a straw. (Wait, did he just say "the rest" after "maximally exhaled"?) I heard that. Yes, you can't exhale all of your air because the pressure in the balloon is higher than atmospheric pressure. In my case, I had another 400ml of air. Then I emptied the air out of the balloon into the container. This is easy and leisurely once you figure out the trick, but it can seem next to impossible at first. Hint: don't try to submerge the balloon. If you grab the lip of the balloon mouth only, and avoid pinching the neck, you can control the air flow very well. There, I had measured my vital lung capacity (VC). It worked great, and compared with the last circus event when I measured VC it was much easier. Now I had to figure out how to get from VC to RV. The clown who wrote http://hans.fugal.net/density kind of left this step vague. I've remedied that and added a page to my spreadsheet. For the curious, my RV is up from 2.0 liters to 2.2 liters, and a total lung capacity of 8.2 liters.

Remember that system I came up with for calculating body fat percentage using a gallon jug in a swimming pool? I always let the computer do the calculations for me—I have a little script that I run that updates my weight graph. But not everyone is as geeky as that, and formula is not that simple, and when you add units conversion in it gets downright hairy. I finally figured out how to generate a nomogram. Now you have no excuses.

I had a heck of a time getting VMWare Server running on Ubuntu 8.04 (Hardy Heron). The problem is that the vmmon and vmnet modules fail to build against kernel 2.6.24. A little googling quickly reveals that you want the any-any-update patch, but that didn't work for me either. To be specific, vmware-any-any-update117c.tar.gz did not work. It turns out vmware-any-any-update-116.tgz works great. Maybe 117 is for the 2.6.25 kernel or something. So, you do the vmware installation except for the vmware-config.pl step. Then you download and extract the above tarball and run runme.pl. Simple enough. But when you try to run it, you get errors like this: /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2) /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6) I'm not sure what the right way to fix this is, but this way works for me. sudo cp /lib/libgcc_s.so.1 /usr/lib/vmware/lib/libgcc_s.so.1/

Have you ever rolled a cable? Maybe I should ask, how many cables do you roll a day? Don't forget the headphones, laptop power cord, extension cords, hoses, etc. And what happens every single time you go to unroll one of these cables? They get all tangled up. Guaranteed. Well it doesn't have to be like that. There is a simple way to roll cables that is easy, avoids tangles, and lies well. Well, actually, two ways—one for big cables and one for small ones like headphones. Oh, and did I mention it's good for the cables, and the way you have been doing it is bad for the cables? For the big cables, watch this video. Go on, I'll wait. For small cables, like headphones, raise your index and pinky fingers and wrap the cable around them in a figure eight. The figure eight nature does the same thing as the over/under technique for larger cables, preventing tangles, and it also makes a nice compact easy-to-stash roll. See this lifehacker article

I came across this article this morning. It is a well-supported discussion of ergonomics, and where and why they've gone wrong in the past. Of most interest is putting the monitor down low, and they make a pretty good case for it. Look at the image and imagine the lower monitor instead as an LCD attached to the keyboard. Look familiar? I may have to reconsider my plan to put the monitor up at eye level. I'll have to pay more attention to things as I use my laptop. My primary concern is not dipping my head forward, which isn't great for the neck. But, I haven't had much discomfort in using my laptop as primary computer for the past couple of years, aside from elbow/shoulder discomfort because of sinking into the couch (not a problem when at school with a chair and desk, although the desk is a tad too high). A comfortable banana chair (with a high enough back to support my head) is sounding promising. What do you think? Is the monitor low or high better in your anecdotal experience? Incidentally the bit about indirect lighting is spot on. My favorite is indirect outside light (window orthogonal to monitor), but a natural white bulb in a task light pointed upwards towards the wall in a dark room works well too. Anything but those blasted flickering overhead fluourescents.