Muller's World
I had to replace my desktop computer at the end of last year. I bought an HP Pavilion gaming PC from Walmart cause it was cheap and I was in a hurry.
This was a Windows 10 system that booted with UEFI, a technology I have largely managed to ignore, and I was initially unable to figure out how to get it to boot to Linux. I had simply moved my hard drive from my old system to the new one, and I achieved some degree of success by disabling secure boot in the BIOS and enabling legacy boot, but I couldn't find a way to either disable the UEFI boot or to force legacy boot to happen first. But I seldom reboot, so I punted on the problem.
Of course, when we went on vacation last week there was a power failure due to a storm the day after we left. This took my system down for a week. I came home determined to get it to automatically boot into Linux in this situation. Read on to hear how I ultimately solved the problem. Read More
Around mid 2019, and after about 15 years of regular use, I'd started having some hardware problems with my Digitech RP-300A effects pedal (footswitches worked intermitently or not at all, expression pedal couldn't do the full range of values...). By early 2020 I decided it was time to move on.
Though I generally thought the Digitech was a great product, I had become a little bit frustrated by some of its limitations and I wanted to try something more. I had a pretty good idea what kinds of features I wanted:
-
Footswitch Configurability. I wanted to be able to punch in specific effects, as well as toggling between programs.
-
Portability. I'd been occassionally playing gigs in NYC in 2019, and I really wanted something that would fit in my gig bag.
-
Open Source Effects. I wanted to be able to use the same effects that I use while recording in a DAW, so that I could recreate my recorded sound live.
-
Expandability. I wanted to be able to hook up other midi controllers and USB interfaces to the device.
The MOD Dwarf ticked most of these boxes, but it didn't look like it would be generally available until at least December of 2020 (and in fact, at the time of this writing, still isn't). So I decided to take a swing at building my own Raspberry Pi based pedal.
What follows is the story of how I did it, presented in the form of a sort of "how to" that others can hopefully immitate. I've been very satisfied with the results, and the software is continuing to evolve. Be warned, if you want to do something similar it will take a bit of time: I'd estimate the whole project took me between 20 and 40 hours over the course of about a month. The materials probably cost under $250 in total, including shipping. There are a couple of special pieces of hardware that I 3D printed, if you don't have access to a 3D printer it shouldn't be too difficult to craft some substitutes. A Dremel rotary tool is extremely helpful for cutting openings in the box.
I've dubbed the unit the "Hog-1 Pidal." The "Hog" part comes from my internet handle ("mindhog") and the "Pidal" part is a bad pun on "Raspberry Pi" and "pedal" (I suppose any Pi based effects pedal could be referred to as a "pidal").
So if you're interested, read on! Here's a bad quality video of the unit in action. Read More
So I must admit, I've pretty much come to accept pulseaudio over the past few years. We've come to a sort of odd truce: it has mostly stopped being a PITA, and I have mostly stopped trying to remove it from my system. Of course, any such cease-fire, where the participants still truly dislike one another, is bound to be a fragile one.
So it came to loggerheads again just recently when I did an all too infrequent "dist-upgrade." Things were kinda bouncy all over the place at first, but over the course of an afternoon I got everything sort of stabilized. But then, at that point, ausio wasn't happening at all.
At first I just killed pulse and moved the binary out of the way so it wouldn't restart (I know there's a better way to do that, but honestly with pulse I'm way beyond caring about being righteous) and of course everything worked fine at that point. If the pulse libraries can't find the daemon, they just try to go directly against alsa. But at some point I discovered that minetest audio wasn't working so I figured I had to dig a little deeper.
It looked like pulse wasn't seeing my audio card (difficult to say for sure because tools like pavucontrol don't give you the alsa names for the devices). A bit of googling and tinkering soon revealed the problem: timidity (also running on the system for some unknown reason) had beaten pulse to the sound card.
So it seems like if you had a fancy newfangled sound daemon that wanted to control every audio device on your system and also a fancy newfangled system control daemon that was introduced ostensibly to deal with dependencies between components, you'd be able to defer initialization of a program like timidity until said sound daemon was up and running, right?
Finally updated my music page (it's finally on par with my soundcloud page). Check it out.
My blog is back online. I guess it was never offline, but a hard drive crash a few years ago robbed me of all of the source code, including the code used to generate it. The output was still up on my server, but not easily modifiable.
I've taken the old static files and chopped them up and written a new site generator script in Crack. The site now has a whole new look that's a lot easier to deal with on phones and smaller screen devices as well as being easier to read on a modern desktop monitor. And of course, the RSS feed is back online.
Now if I can just remember to keep posting every now and then.
When we last left Mike's Mail Client, our protagonist was left with a client with message integrity and a journal... that still stored its canonical message indexes in GDBM files.
Kicking an old habit can be hard. You're like "well, what if I'm doing something really wrong here? What if I need to go back?"
So at first, I set about trying to make the CSV index files primary and maintaining the GDBM files purely as backup - essentialy inverting the current arrangement for indexes the way I had for messages.
Of course, this isn't at all straightforward. Simply dumping an index maintained from my CSV files kind of defeats the purpose of maintaining an independant store. OTOH, maintaining parallel indexes and journals and attempting to reconcile the two is just a recipe for pain.
I like to avoid pain, so I had been successfully avoiding finishing this effort off until fate forced my hand: I once again exceeded the size limit on my inbox GDBM file.
So to recap where we left off, I had all of my messages stored stored in the filesystem named by their hash values and all of my folders are stored as CSV files.
Neither of these were authoritative, though. Everything was still being loaded from the old GDBM files.
My first step after that was to begin loading from the message store. Unfortunately, the folder indexes stored in GDBM don't store the hashes. To reconstruct them I would have needed to load the messages from GDBM, hash them and then load the same messages from the new message store which would be kind of silly.
The GDBM indexes reference messages by a monotonically increasing numeric id which is the message key in the GDBM file. I didn't really want to mess with the contents of the GDBM files, but it seemed like the best option was to store the hashes in the GDBM indexes.
That didn't work. Many of the folders are too big to allow me to rewrite the index. So during folder write I wrote out another CSV file mapping the GDBM message key to the message hash. When we load an index, we just lookup the key in the message key to hash index and tack on the associated hash.
With the addition of the index-to-hash lookup, everything works quite nicely. But then, there's the garbage collection thing.
Now that all of my messages are stored in my filesystem, my next task is getting to where I can look them up quickly.
The existing spugmail client stores its its indexes as a single object in each folder database. Messages are stored under monotonically increasing integer keys, and each entry in the index contains a reference to its message object, in addition to some other fields (sender, subject, date...) that are displayed in folder's list view.
I want the index lists to be stored as flat-files so they can be easily manipulated by other tools. I chose the CSV format because it's both simple and ubiquitous. But CSV has some problems.
Many years ago, I wrote my own e-mail client called "spugmail." I wrote my own because I wanted something I could run in an ssh session and I had used elm and pine and they just too slow when dealing with an inbox as large as mine. So I wrote spugmail.
Spugmail is fast and light. Written in python with a curses UI, it stores messages in GDBM files, one file per folder. Since GDBM is strictly key/value, there is some trickery involved in preserving the ordering of a folder (which seemed like a good idea at the time). So I store the entire index of each folder as a single object in the database, writing it upon leaving the folder and storing journal entries for times when it goes down prematurely (usually due to a power-outage and a broken battery backup).
The whole thing works pretty well, but in recent years I've become more dissatisfied with it. For whatever reason, my GDBM setup doesn't garbage collect very well, so every once in a while my inbox file grows to 2G (even though there's no where near that much data in it) and I have to move it and start a new inbox. There's also the fact that curses doesn't automatically deal with window size changes, so when I run it in a 'screen' session and pull it into a window of a different size, the layout gets messed up.
After having used g-mail, there are also a lot of g-mail like features that I'd like to add to it, like search and the ability to see an entire thread as one view. These kinds of things don't fit very well with the "one file per folder" design, and (lacking good tests) I've grown rather change-averse because breaking something can leave me without e-mail, sometimes at a very inconvenient time.
So I've decided to finally undertake some major changes to the client. A big part of this is to make the system more modular and transparent, so I can experiment with new tools without fear of breaking the existing flow.
I'm posting on this because I couldn't find anything to solve my problem with a search. I was trying to upgrade the version of the java plugin used by both Firefox and Chrome and was having a hard time. The "check your version of java" web page kept telling me that I had version 1.6.0_18 installed, even though I had installed (confirmed by "java -version") 1.6.0_22. Furthermore, the Firefox plug-ins panel showed that I was using the IcedTea plugin and said nothing about any other java plugins.
It turns out that the file /etc/alternatives/mozilla-javaplugin.so didn't get updated with the java install. To fix it, I ran:
update-alternatives --config mozilla-javaplugin.so
I selected "/usr/lib/jvm/java-6-sun/jre/lib/i386/libnpjp2.so", restarted the browsers, and the new plugin was used. And now I can spend the rest of my life playing Minecraft :-).
A prerequisite for this is that you have the Sun Java 6 package installed. Make sure you have "deb http://archive.canonical.com/ lucid partner" in your /etc/apt/sources.list file, and then do this:
sudo apt-get install sun-java6-plugin
Then follow the steps above to update Firefox and Chrome.
I find it extraordinarily annoying that the more progress we make with Linux, the more we seem to break things that were working fifteen years ago. In particular, consider suspend and resume on a laptop. I have a long history of "works great" followed by "doesn't work at all" then "works but is flakey". Imagine these conditions are nodes in a graph and then insert biderectional edges from every node to every other node and you will have a diagram of my experiences for over a decade when changing laptops and upgrading software. Why is this still a problem?
Most recently, I have gone from "works great" to "works but is flakey," apparently related to ubuntu upgrades. Unfortunately, we now have a fancy power management stack consisting of a power management daemon on top of D-BUS responding to and driving some kernel magic that no longer looks like anything like the "/proc/apm/suspend" device I used to be able to just write to.
So what happens now is some percentage of the time (one in four, maybe?) that I hit Fn-F4 (my Thinkpad's suspend key), nothing happens. Of course, this normally happens when I need to go somewhere NOW and can't spend a lot of time debugging the problem. And really, who wants to debug this? So I normally just swear and power down.
I'm suspicious of the gnome-power-management daemon - sometimes when this happens it's down, sometimes killing it and restarting it lets me suspend again. So I wrote a little crack program that makes the three library calls used by the power manager to suspend the system. And here it is:
#!/usr/local/bin/crack
import crack.lang FreeBase;
import "libgobject-2.0.so" g_type_init;
import "libupower-glib.so.1" up_client_suspend_sync, up_client_new;
class GError : FreeBase {}
class GErrorWrapper : FreeBase {
GError error;
}
voidptr up_client_new();
void up_client_suspend_sync(voidptr client, voidptr unknown,
GErrorWrapper error
);
void g_type_init();
g_type_init();
up_client_suspend_sync(up_client_new(),
null,
GErrorWrapper()
);
It feels really good to finally be using crack for these kinds of problems, and I'm very pleased that it's actually the best tool in my arsenal for these kinds of problems.
I'm finally getting around to blogging this: I'm happy to announce that after about 9 months of development, Crack 0.1 is released.
Crack is a Java/C/C++ like scripting language that compiles scripts and modules directly to machine code. The language is now at a point where you can produce real code in it, although there are a lot of features that are still missing or broken. This is an alpha-level release intended to show off the core of the language. Don't use it for anything serious yet.
The code is mostly my own, done as a 20% project at Google, but includes some very notable recent contributions from Shannon Weyrick, one of the Roadsend PHP developers. Shannon got involved in the project after my talk on it at MHVLUG in May, and continues to be a very active contributor. Without his help, the first version would not be released yet.
The completion of this release has freed us to work on a large refactor of the codebase: we're in the process of reworking the most awkward elements of the system so that we can continue to move forward with development at a rapid pace. 0.2 will feature the fruits of this refactor as well as lots of bug fixes and new feature additions. At this time, I'm targeting September for the next release.
Closing this post with the Crack "hello world" program:
#!/usr/local/bin/crack import crack.io cout; cout `yo, wanna try some crack?\n`;
I've been doing a lot of clean-up lately in preparation for Crack's first release. I had a number of modules laying around in various states of completion that I'm finally checking in: the GTK bindings, PCRE bindings, and of course, the container module.
Containers were particularly problematic. I only had one container type, (the linked list) and it didn't work. I fixed up the code and added an Array class (similar to C++'s std::vector). But there were still no associative arrays - so I started work on a Red-Black tree implementation called RBTree.
Red-black tree's are a kind of binary tree where nodes are colored red or black and have special constraints to keep the tree from becoming unbalanced. While I haven't bothered to reseearch the domain, I assume that they perform pretty well because the C++ standard libary folks used them for their std::map implementation.
I mostly ported C code from the Wikipedia articla for this - there are five different cases for insertion in an R-B tree. After about an hour on the train Friday night and in my living room the next morning, I got this working and had a tree that I could insert three strings into. W00t! That's when I turned to look at deletion.
It turns out deletion has five different cases, too. At this point, I said to myself "ya know, there are a lot of good things that are not going into version 0.1, and red-black trees is one of them."
The threat of feature creep has been averted. Crack pioneers will have to make do with arrays and linked lists for a while.
I recently did a series of upgraded to my ubuntu desktop to bring me from the Hardy (8.04) to Karmic (9.10). I was disappointed to discover that after boot up, GDM completely ignored my .xession file and instead placed me in the default window manager. Not good.
GDM is the program that gives you a login prompt, checks your user id and password and then starts your X windows session. It's generally pretty configurable, so I poked around for information on how to get it to what I wanted (namely: don't try to start the session for me: just use my shell script).
There's a system Xsession shell script in /etc/gdm that gdm runs after login. It accepts the name of the window manager binary that you want to run as a parameter. If this parameter is "default" it runs the default window manager, if it is "custom" it runs your .xesssion script. You can add a configuration file to /etc/share/xsessions - the "Exec" parameter in the file specifies this parameter.
Unfortunately, this doesn't work. Before checking for the "custom" value, Xsession runs all of the scripts in the /etc/X11/Xsession.d directory. The last of these is 99x11-common_start, which effectively does an exec on a sanitized value of your Exec parameter - unrecognized values revert to the default window manager.
So I decided that the best thing to do is just to short-circuit the entire Xsession.d startup process. I added a file named 00-local_xsession to /etc/X11/Xsession.d with the following contents:
if [ -x "$HOME/.xsession" ]; then
exec sh "$HOME/.xsession"
fi
"If there's an .xsession script, run it and don't run anything else." Works for me. I am once again the happy master of my own X-session. Hopefully this won't break again in Lucid.
Working my way through the news I haven't read yet, I came across this article on Slashdot. It's about Carl Woese and Nigel Goldenfeld's theory that Darwinian evolution is a phase, and that prior to this was an era of horizontal gene transfer - where (presumably single celled) organisms were a lot more promiscuous about sharing their genes.
This pre-heredity world sounds to a me a lot like our modern information revolution: people sharing memes, open source code and (gasp!) media files freely across their computer systems.
So I have to wonder: Is our current predicament the precursor to a new form of life? And more interestingly, is the current trend towards highly granular copyright the mechanism by which our AI-descendents will guard their basic representation and usher in some sort of informational Darwinian era?
It saddens me to think that the ideals that I embrace - of free communication and the unmitigated sharing of ideas and information artifacts - will be regarded by our heirs in the same manner that we now regard viruses.
I'm happy to announce the release of ODB 0.5. This release includes changes that I've done over the past year. The major new feature is a whole new interface that moves away from concrete table types and Berkeley-like concepts, instead favoring a schema-driven relationship between program objects and database entries.
I'm currently using ODB on a number of my own small projects and on a couple of projects at Google. I've been really satisfied with the reliablity and maturity of the code and the elegence of the new interface.
I may do another minor release at some point in the future to introduce a few small enhancements and some more documentation, but at this point I'm pretty happy with the state of this package: it does what I need it to do. These days I'm spending most of my time on a different project, so I don't expect to do any major work on ODB in the coming year. As always (with any of my projects), I remain happy to accept patches or fix bugs.
I recently watched two Google tech talks that I found pretty interesting, both are available on YouTube.
The first was "Lessons from LFTR," which discusses the history of the development of Liquid-Flouride Thorium Reactors. The way that this promising technology was overlooked, combined with the similar story of uranium-based breeder reactors, fills me with deep resentment and cynicism about the trajectory of nuclear energy adoption. For me, it confirms more than ever my belief that the best thing we can do to ensure a future of plentiful energy is to get our government out of the decision-making process.
The second, "Fun with Light," is a discussion about some of the interesting classical and quantum properties of light interaction. It includes a brief analysis of the amount of energy necessary to create something with the interactive properties of a light-saber.
I hiked up Bull Hill about two weeks ago. There's an unmarked trail that diverges from the main trail along the side of the quarry. I figured it probably ran along the top of the quarry, so I thought I'd check it out.
Sure enough, the little unmarked trail, while trecherous at points, yields some fantastic views of the quarry and the surrounding region. I started recording it on MyMaps (best Android program, evar...) at the end of the trail, walking back to the main trail and then doing my normal loop back up to the top of hill and down around through the valley between Bull & Breakneck. The resulting map is here.
One of my LUG-buddies, Chris Knadle, pointed out some problems in spugedit and spuglib so I've cut new releases of both packages. These mostly include small fixes, but the new spuglib also includes the next generation of my web framework code.
I've used a number of different editors over the years - IBM's "E", Brief, jed, a brief stint with emacs, and then vim during the finance years. I was never terribly happy with any of them. So in late August of 2007, I started to write my own, starting with little more than save and load functions attached to a Tk text widget. The project stuck and became my primary working editor after about three months. I've continued development on it as a 20% project at Google, and now it's finally at the point where I'm somewhat comfortable releasing it to the outside world.
I was originally calling it "yed" (as sort of a combined pun on "jed"/python/"yet another editor") but it looks like the "yed" name is already overloaded (including another opensource project) so I'm falling back to my usual namespace and calling the project "SpugEdit." The program name and internal references are still "yed."
SpugEdit is still very much experimental. It has a few warts. And if you're already very happy with your editor, SpugEdit is probably not for you. But if you want to try something new, and you like the idea of using python to control your entire world, you might want to give it a try.
The project page is here. Happy hacking :-).
Ok, so this might be the four Dogfish Heads talking, but right now I'm thinking: "Hellboy 2 - BEST MOVIE EVAR!!!" Well, maybe not that good, but certainly far better than the original. Not sure how this missed critical acclaim, but then, so did Fight Club.
After about four months of running ODB as the backend for my home jukebox, I found a bug. I'm very pleased that a piece of software this complicated has proven this reliable so far and that finding the problem took only minutes. Unit tests rock!
So I've released ODB 0.4, which fixes this and adds the ability to automatically recover a database from its logfiles if state files are absent. Enjoy!
I've been giving a lot of thought lately to ODB 1.0. I'm considering completely changing the interface (preserving the existing interface as a deprecated feature) and changing the heap file implementation in order to improve free space management. I'm also seriously considering porting the library to C++. So cool things may be coming down the ODB pipe :-)
My recent setup of a nexuiz server on the enduden host made me interested in monitoring our bandwidth usage - I don't want to infringe too heavily on our monthly usage. So I searched around for a bandwidth graphing tool that I could use with Apache and found MRTG - the Multi Router Traffic Grapher. It seems like a pretty nice tool for monitoring traffic (and lots of other stuff).
Setup was somewhat less than trivial. So I've done a little write-up on the process.
I was working from home last week while recovering from minor surgery, and fortunately, I didn't discover nexuiz until Friday - because from that point on, my productivity was dead.
I've been a huge fan of the deathmatch game genre since the days of QuakeWorld, and while there have been some improvements since then (mostly in the way of graphics, bots and weapons selection) on the whole, I think that the form has gone downhill. Deathmatch should be fast and exciting! In some of the newer games it's like you can feel the weight of all of the weapons that you're supposedly carrying.
Nexuiz takes me back to what excites me about the game - lightning fast gameplay, awesome close combat. That combined with beautiful graphics, a nice selection of weapons and a collection of the best of breed of game modes (CTF, Team Deathmatch, Domination and Runes) earn it my vote for Best Deathmatch Ever!
Nex is free (as in both beer and speech) and uses the DarkPlaces engine, based on the original Quake 1 engine with some Doom 3 like enhancements. If you're into deathmatch, you simply must check this one out. If you're on the US East Coast, you'll probably meet see me there. Nexuiz has reignited my love of the game.
It was bound to happen. After five years of working in Manhattan after 9/11, at some point I was going to be harassed at one of the subway search points. I have always resolved that when this inevitably occured, I was going to refuse to be searched.
Perhaps it was that conscious predetermination, perhaps it was just the attitude fostered by years of refusing everyone who wants a piece of my attention out on the streets of New York, but when I walked up to the turnstile last night (glancing at the uniformed men beside the table; then quickly refocusing my gaze back to my flight path in a vain attempt to evade their attention, then ignoring their first "excuse me, Sir" request) my reply to their unspecified but obvious demand was an instantaneous, flat, emotionless "No." This was the kind of "No" I give to the hustlers who persist to the point where some action is required on my part.
Without breaking stride, I turned and walked to the nearest exit. "Ok," I heard one of them say. He might have said something else after that, I wasn't paying much attention at this point. They can refuse to allow me through the turnstile, and I can refuse to be searched. Neither party was contesting the outcome of this particular stalemate.
I walked one block West and took the A/C/E line instead.
I suppose that if I were a more diligent proponent of freedom, I might have engaged the police in a discussion as to exactly why I refused to honor this little farce. But the fact is, I'm simply not that confrontational. And even if I were, I have to question the value of such an exchange. The likelihood of making an impression that might end up making some kind of difference seems next to nil.
But there is one thing that each of us can do in the interests of diminshing the grip of the police state: refuse to cooperate. Hold the line as hard as you can. Just say "No."
The paranoid part of me wonders if my refusal has somehow marked me: I suppose that at least the officers involved might recognize me the next time they're set up. In the most paranoid case, I suppose that they could obtain footage from the station's security cameras and distribute my image throughout the department. All of this seems highly unlikely. And for now, I'm mostly pleased to have stuck to my principals.
I just put together a new song. It's called "Sound of Thunder." Enjoy.
This is my second attempt at mixing with Audacity. I was pleased with the results.
I've just released SpugAudio and Spug++ - SpugAudio is a wrapper library that presents a common interface for ALSA and ESD based audio that I wrote when I discovered that the newer versions of ESD appear to have broken audio recording (at least on my hardware) which in turn breaks my audio recording toolchain.
spug++ is my common C++ library which SpugAudio depends on. Wurld also uses it, but with wurld I can bundle it. With SpugAudio bundling is more difficult, so spug++ is now an independent entity.
On a somewhat related note, I've just discovered that audacity works pretty well on my laptop (for situations where I can put up with the noisy, monophonic input that I get from my laptop) so I'll probably be using audacity a lot more for composition in favor of my own tools - I can bring the laptop down to the basement where the rest of my equipment normally lives. And as for the "noisy" part, audacity includes a noise-remover...
I've just released ODB version 0.3. I've done quite a bit of work on the native database implementation over the past few months, and at this point I am inclined to use ODB for all of my python data storage needs.
I've learned that I can work on my open source projects in my 20% time at Google, so ODB is now one of my 20% projects. As such, portions of the code are now "Copyright Google Inc."
I've also decided to move away from my own BSD-ish license and onto something more standard - in this case, the LGPLv3. For a long time I used my own license because I feared the GPL to be too restrictive for businesses to be willing to use GPL code. None of the less restrictive licenses in use seemed to express what exactly I wanted. These days, however, it seems that pretty much everybody is using GPLed code, and I've come to accept that a lot of the restrictive provisions of the license (particularly some of the anti-patent provisions of GPL3) are really important for the FOSS community. Also, as it turns out, it is now the special one-off licenses like mine that hinder business adoption of the code - they create a whole new hurdle of having to be approved by the legal department. So ODB is now released under LGPLv3.
I've been thinking a lot lately about "Personal Cloud Computing."
I currently have unix accounts on 5 different computers: laptop, desktop, and three shell accounts on remote machines. I deal with keeping a somewhat homogeneous environment on all of them by copying files around. Mercurial helps a lot with this, lately I've been trying to keep my customization files in mercurial repositories - when I set up a new machine, I just clone one of the mercurial repos and rebuild my home directory from it.
But the core problem remains: I have five computers. When one of them is unavailable, for any reason, I don't have access to its services. I mostly try to keep things backed up (both by storing the important stuff on multiple machines and occassional explicit backups to a 500G USB drive) but this process relies on my remembering to do it, so at some point, if I continue like this, I'm going to lose data.
So here's what I want: I want my data and services to live as an autonomous self-replicating swarm on all of these machines. When a machine becomes unavailable, I want the other machines to step up and fill the gap. I also want to be able to use the individual machines whether or not they have a connection to their peers - so I can work on my laptop on the train and then when I connect it to the internet have it automatically sync with everybody else.
This is a tall order. Some of these things have been implemented in distributed object and message passing paradigms. The "offline activity" modes exist in modern distributed version control systems. To my knowledge, these technologies have never been combined to implement the kind of thing that I'm describing - essentially a "distributed account" concept.
Adding to the difficulty is the problem of compatibility: even if I were to create a framework with all of these properties, all of the applications that I use every day - the chat clients, the e-mail program, firefox - would have to be modified in order to make use of it. And then there's the problem of getting these applications themselves uniformly distributed to all of the machines from which they are used.
Clearly there is a lot to be gained from moving in this direction. I think that the best way to get there is through a series of baby-steps involving a patchwork of both architecturally pure components and virtualization technologies. In particular, I think a good first step would be to virtualize my home directory with a FUSE-based distributed filesystem.
I think this is an area that's likely to become huge where the Linux community has an opportunity to lead the way.
Last weekend was the date of our much anticipated Winter hike of 2008.
Instead of the White Mountains in New Hampshire, our normal "big hike" location, we decided to try the Adirondacks this time. Adirondack State Park is comparable in distance to the Whites, about 4 hours of driving for me and 5 for the rest of the guys (from Connecticut). We settled on Lake Placid as our base of operations, it being right next to all of the high peaks.
We drove up during the day of one of this season's few big storms - they ended up getting 5-10 inches in our area, but we left early so the roads were still passable and we were driving North, out of the storm. By the time I got to around Lake George, the snow had pretty much subsided. It started up again when I got into Lake Placid.
Lake Placid is an amazing place to be in the winter. Unlike southern NY,
which pretty much shuts down during a big snow storm, the north country is
entirely comfortable with snow. And in Lake Placid in particular, it seems like
everybody is there for winter sports. Its also a small enough town so that the
preferred mode of travel is by foot. During both daytime and evening there were
hundreds of people out on the sidewalks, patronizing the many shops and
restaurants.
The Hike
As I've suggested before, I've been spending some of my time working on a suitable replacement for Berkeley DB. I've finally got this to where I'm ready to start using it for my own data-storage purposes.
The project is called ODB - it's a pure-python package that can serve either as a wrapper for BDB or a complete replacement. This initial release is still very immature, but if you need a lightweight database system and can do without the performance of BDB (or the many headaches that it produces) you might want to give ODB a try.
I've had Ubuntu on my desktop machine for some time now. It had been a RedHat machine since birth, but I'd let it stagnate until it was just too far behind to easily upgrade to Fedora, and I'm more of a Debian fan anyway so I just bought a new hard drive and started fresh. When I originally installed Ubuntu, I was unable to boot any of the stock kernels. At the time, I shrugged this off and built my own kernel from source. This has worked fine for me ever since.
But lately I've needed to add some very basic features that I omitted in the original configuration (like USB and APCI support) and rebuilding my source kernel every time (and applying all of the necessary additional drivers) has started to become tedious, so I've decided to revisit the issue of getting the stock kernels to boot.
There are only two companies that I've ever really wanted to work for. The first is the small consulting company that I helped to found over ten years ago. The other is Google. Of all of the software companies out there, Google is the only one where I get the impression that they're actually doing it right.
I received an offer from them in late October. I'm happy to say that I've accepted and will be starting with them on Monday.
I'm cautiously optimistic. This should be an interesting ride!
PyESD is a python interface to e-sound that I made years ago. It's mostly just a SWIG wrapper around the e-sound API, but it also includes a more object-oriented interface to the package.
1.1.2 is a minor upgrade, the package had fallen behind development in Python and SWIG. The new version brings it back up to date.
I am so pleased with myself. Tonight I made my own tomato sauce, and it came out fantastic.
My previous efforts with sauce have been as an "assistant chef" working with others who had made sauce before. I was never very satisfied with the results.
I think I've reached the point where I can say I actually hate Berkeley DB.
It wasn't always like this: I really liked it at first. When I have to persist things, I don't want to deal with slicing them up into relational tables. It's so much easier just to dump a serialized object whole. I once used dbm and gdbm files for things like this, but these kinds of databases are sorely lacking in many respects: no transactions, no cursors... So for me, BDB seemed like everything I wanted.
Except for when it would inexplicably get into a wacky state. Like when it would run out of locks and I'd have to recover the database and try to figure out how in blazes my code was leaking locks. Or the handful of times when I just ended up with corrupt files for no apparent reason. And of course there are the deadlocks: get halfway into a transaction and then have to start over again. By early this year, I was definitely irritated with BDB.
But the versioning thing has really transformed my irritation into hatred. I was moving a database onto a new system - from 4.2 bdb installation to 4.3, and of course bdb couldn't deal with the old file versions. (I can't understand why you wouldn't write a new version of a database library so that it could just transparently deal with older versions of the database, unless it's to prompt users to slowly go insane and finally switch to Oracle)
So how would you expect to be able to upgrade to the latest version of the code? db_migrate, perhaps? Nope. Nothing so straightforward. I tried what would seem to work based on my limited understanding of bdb: checkpoint the existing database, then dump the tables and load them into a new database (actually, I first tried just dumping all of the tables and the logfile, but db_dump wouldn't dump the logfile).
So I tried running the old version of db_checkpoint (for the version of bdb that the database was built against) and it complained about the environment version being wrong(!!!). I then tried running the checkpoint program for the new version of the database. It ran successfully, but it didn't touch any of the table files or the existing logfile, but rather produced a new logfile - which is completely the opposite of what I thought checkpointing was about.
So just for the hell of it, I tried running my application against the new database (i.e. logfile), and what do you know, it works! And I have no clue what just happened.
So I guess my first priority is to write a utility to completely dump my database so that if I ever run into this again, I can just blow off the bdb migration process and rebuild the database from my own, version independent, dump file. And then get back to work on my BDB replacement.
It's been a long time since my last release. Too long. I had one major goal in mind for this release: converting the player object to a normal Moveable.
The "player" object - which controls the camera position and who's motion can be directly controlled by the keyboard - was special. He had his own collision detection which was based on a modified point-collision algorithm - good enough for walking around in the maze, but just barely. Not good enough to make him appear solid to the rest of the objects in the world. In fairness, the players collision detection predated the collision framework, so a retrofit was inevitable.
But the original player collision algorithm was sphere-like - in order to replace it, I had to bring the sphere collision code up to snuff. Specifically, I had to implement the dreaded Sphere/Plane collision check.
Encouraged by my past success figuring out an efficient sphere/sphere collision algorithm, I ignored most of the sphere/plane info on the web (most of which was pretty bad) and set about figuring out a lot of the math on my own. This was quite a challenge - a bit too much of a challenge - and I spent about a month of morning train rides on the problem.
But I did it. And so I'm happy to release wurld 0.5. Happy hacking.
In the name of all that is sacred, please, please don't bring your whole family (especially the screaming infant) on a commuter train.
-
It's going to be expensive.
-
You probably won't be able to find seats together
-
Your baby's screaming is going to ruin the day for about a hundred tired, overworked people who have to make this trip every stinking day.
So save your money, save your karma. Avoid the commuter trains. Hell, rent a limo. For what you're paying in train tickets, you can afford it.
Thank you.
I'm now on the last day of my two week vacation. I started the two weeks with a weekend trip to New Hampshire for more hiking in the Whites (we did Height Mtn. and the Carter Dome). Came home on Monday, relaxed and took care of house-stuff on Tuesday, and then on Wednesday we went down to LaGuardia airport to catch a flight to Portland, Oregon, where we stayed for a week.
We saw the most impressive thing about the area while we were descending in the plane - Mt. Hood and Mt. Adams. These 12,000+ foot monsters tower above everything else in the region, and our flight path gave us an excellent view of Hood to one side and Adams to the other. I wish I could have taken pictures, but we were on our descent and the use of electronic devices had been disallowed.
Wurld 1.4 is out - the main new feature is positional audio.
This release was a lot longer coming than I wanted it to be - I ran into some heavy problems with all of my computers which put a monkey wrench into the works. Things are more or less back to normal now, so hopefully I'll release again in early July.
I've just released wurld 0.3. The primary feature that I've been working on for the past month is the collision detection framework. This was a tough nut to crack, but at this point I'm just bursting with ideas on the subject. The new framework is the first word on it, but it won't be the last.
I think that with the new collision detection code, it is now actually possible to write a game with wurld. I think that's something that I'm going to try to do in the weeks to come.
One thing that can be said about working in Manhattan (and I consider it to be a positive thing) is that you can dress entirely in black and no one will give you a second look. In fact, you can dress entirely in a chicken suit and no one will give you a second look. Granted, the chicken suit would have attracted more attention, probably a few comments, perhaps a polite request to leave early, at a job at a major bank, but the fact remains - in New York City, nobody really gives a pile of gutter-strewn excrement how you dress.
So that sheds some light as to why I am dressed unabashedly in black today. Black slacks, black shirt. That and a recent interest in the music of Johnny Cash. And the fact that I dress entirely in the dark (especially since the recent [and premature] onset of DST). It has nothing to do with the recent departure of one of my colleagues, who brought a lot of good ideas, a lot of good code, and a nearly religious dedication to best practices to the job. Arkadiy, if you are, in fact, out there google-stalking me, I salute you, brother!
Now don't get the wrong idea, Arkadiy didn't die or anything - he just quit to find a job much closer to home. Good for him, I say. But anyway, today was his last day, so we all went out drinking. I'm generally not much of a drinker anymore (got enough of that in my twenties), but seeing as how it was snowing/hailing/freezing raining out and and the boss was paying for drinks and I had promised my wife that I'd meet her on the 7:18 train so we could go home for our ritual Friday night spend-some-time-together-fest, I sucked down two Sam Adams in the space of about half an hour before patting Arkadiy on the shoulder, wishing him the best, and heading off across the frozen tundra of mid-town between 7th and Madison. When Jenny and I got back to our lovely, iced-over town of Cold Spring, we proceeded to go about our evening plan of picking up a pizza at "Cold Spring Pizza" and going home to eat the pizza and drink the Ethiopian honey wine that she bought last night - the latter putting me way over my limit.
And so we arrive at the crux of this post. Lots of alcohol + a low-calorie diet + absence of recent tolerance through drinking experience leads to rambling blog posts. Sad but true. What's it gonna take for us all to wake up and realize that this is a problem? What's it gonna take.
I've just released Wurld 0.2. Changes include scriptable key bindings, automatic tesselation of large polygons to improve lighting, a framework for "HUD Objects" ("Heads-up-display" - text and bitmaps and the like), and a number of general improvements.
I've started work on general collision detection, I was hoping to get it into this release but collision detection is a tough nut to crack and I'm trying to follow the "release early, release often" formula.
I've decided that I'm going to try to split up my personal programming time, spending half of it on Wurld and the other half on a web project that I started last year, Spuden. We'll see how that goes.
Almost a year ago, I was playing around with OpenGL, building the core of an FPS style gaming engine I was calling "wurld". Well, holiday season of 2006 came around and I didn't have anything fun to look forward to, so I decided to blow the dust off of wurld and do some more hacking.
My engine now supports lighting, python bindings, SDL and GTK widget drivers, and (thanks to a python module) 3D turtle graphics! That is, you can generate models using a 3D turtle (like in the old LOGO programming language).
I've also bundled all of the components together into one easy tarfile: wurld-0.1.tar.gz, complete with all the nifty configure and automake stuff you've come to expect from every source tarball you download.
Current requirements are: SDL 1.2 (earlier versions may work), GTK 1.2, libpng, Python 2.4, and of course, OpenGL. Enjoy!
I really shouldn't be messing around with this any more - I've got more important things to do. But it's just so much fun...
So here's the problem: I have to deal with some code that lives in CVS repositories in places where I don't have access to those repositories (from my laptop on the train). I'd like to be able to manage the code using Mercurial for my own purposes, but also keep it in sync with the CVS repository.
I was thinking of writing some tools that would manage this for me, but then I had a really cool idea: check-in my CVS meta-data into Mercurial.
The "CVS" subdirectories in your CVS tree keep track of the baseline that you checked out from. By checking them in, you are effectively saying "this mercurial revision corresponds to these revisions in CVS." What you end up with is a hybrid working directory - managed both by CVS and Mercurial. You can freely clone it and push and pull changes - the CVS meta-data stays with it.
So now, I can check-in as many change-sets as I want into the mercurial repository. When I want to sync with CVS, I just do a CVS check-in, then follow that with a mercurial check-in to update the meta-data files that were changed by the CVS check-in. It should also be possible to do this incrementally (splitting up the mercurial change-sets into separate CVS check-ins) by backing up to the revision corresponding to the last CVS check-in an:d then committing the new revisions one by one.
Changes in the other direction work the same way: "cvs up" followed by a Mercurial check-in (it may be desirable to check-in the meta-data changes separately from the managed files themselves, I have to think about that one).
Other concerns (that I know about at this point):
-
You need to do some extra work for files that are added and removed (should be fairly easy to automate this).
-
This trick only works with a single branch. To manage multiple CVS branches, you'll need multiple mercurial repositories. It should be possible to at least have them based on a common revision, though, which will allow you some flexibility in how you merge them later.
I still consider this approach to be highly experimental - caveat emptor.
I've just taken another step towards bluetooth mastery - I can now send files from my phone to my computer.
My phone has this crappy 640x480 camera built into it. It's not a feature I cared about when I bought it, but because the phone is always with me, I've ended up using it quite a bit, and I now have 81 pictures and 5 short movies on it. I've wanted to transfer these to my computer, but the only way to do so is to send them via Verizon's picture email service at a cost of 25 cents a picture. Now I don't think I'm especially cheap, but I can't see paying 25 cents to upload a single, low resolution image to my computer. Especially when I'm paying $45/month for "unlimited data" and the phone sports USB, infra-red and bluetooth interfaces. Got to be a better way.
I came across this NPR Article about Chronic Candy. Yup, lollipops that taste like marijuana. Although it contains no THC, its sale has been banned in a number of cities. Georgia is trying to institute a statewide ban.
The ostensible reason for this crackdown is, of course, concern for the children. According to George Crawford of the Coalition Against Chronic Candy: "This candy tells young people that marijuana is fun and safe." Presumably, it is now acceptible to ban anything that might have a corrupting influence on the young'uns.
I question the veracity of the stated intent of these anti-candy crusaders. It seems pretty clear that children are not the target market for Chronic Candy. It's being sold in gas stations and headshops, not toy stores and supermarkets.
I think the real reason for the concern is that the very presence of this product ridicules the war on drugs and specifically, marijuana prohibition. And this, of course, is something that cannot be allowed to happen because ridicule tends to preceed eradication.
It's the end of an era. Wednesday night, Jenny and I finished watching the last episode of Angel on DVD. This concludes the journey through all seven seasons of Buffy and five seasons of Angel that we started over a year ago (last September).
On the whole, our favorite periods were Buffy season 6 and Angel season 4. The last season of Buffy was a tremendous conclusion. We found the last season of Angel to be a little choppy - much less coherent than the previous season, suggesting that the series was cancelled prematurely and the writers had to scramble to bring it to closure. That said, we both enjoyed the last episode immensely and thought it was a good conclusion.
So at this point, I think we've watched all of every television series that Joss Whedon has ever done. Next up is season one of "Lost," which we've both heard good things about.
Last week I needed to get Outlook to delete all of the messages in a folder, so I decided to try writing a macro in VBScript. Now, I started programming way back in the early 80's, so my first programming language was BASIC. On a very small number of occassions in the years since, I have had an opportunity to see how MS has evolved the language.
My latest experience has done nothing to improve my impression of this company or the language. VBScript appears to me to be nothing more than a twisted perversion of the original language into the era of object-oriented scripting languages.
There are two major approaches to multiplexing communication channels on servers: thread-per-connect (where multiple threads each manage a connection with synchronous send and recv calls) and poll/select (where a multiplexing function is used to wait for connections to become readable or writable). The two in-house communications packages I've seen lately use a hybrid approach, combining poll/select with a threadpool to allow requests to be processed without blocking communication channels, but the fundamental dichotomy remains.
So having used both of the two approaches over the course of my career, and being now involved in work on yet another communication package, I was curious: which of the two approaches performs faster on Linux? It was my belief that poll/select would significantly outperform thread-per-select on a single processor box: poll/select seems like it should avoid the overhead of context switching required by thread-per-select.
I was surprised to discover that my belief was wrong: unless I've screwed up in benchmarking this, thread-per-connect performance and poll loop performance appear to be equivalent - or at least too close to call.
The boys and I did our first official hike of the season in the White Mountains of NH yesteday: up Mt Liberty and across the Franconia Ridge to Mt Flume. We have to plan these things well in advance - people need to take time off from work, we have to get a condo, and then there's the general question of everyone's availability.
I was one of the last hold-outs. For years I watched as my friends, my colleagues, my wife (then girlfriend), hell, even my mother got cellphones. More and more I was asked "why don't you have a cellphone?" Hmm, why would I want a cellphone? So my cow-orkers could harass me at any time of day and night? Not interested.
Well, ok. There have been a couple of times in the past year or two when I was wandering around Manhattan trying to meet up with people, jumping from payphone to payphone to call them on their cells, with no way for them to call me when I thought "yeah, a cellphone would be handy right now."
As mentioned earlier, I've been playing around with some OpenGL programming. I've started writing an FPS-style program that lets you wander around a map of colored and textured surfaces. I've been calling this project "wurld" for lack of a better name. At this time, the program doesn't do very much - I can wander around the map-world but that's about all.
I took a tilt-table test yesterday. Basically, this is a test where they try to get you to pass out under controlled circumstances. I had to avoid all food and drink starting at midnight the night before. They hooked me up to an EKG and blood pressure monitor and then I laid back on the table, got strapped down and was elevated to a 70 degree angle.
Without much else to do, I spent the first few minutes talking to the technicians, asking them where they go for lunch and listening to stories about their grueling shifts in past hospitals. After about eight or nine minutes, I started to feel a cold sweat coming on. I reported this to the technicians. Shortly thereafter, I could tell I was going to pass out. I came pretty close to actually doing so, and they mercifully lowered the table. So, in short, I tested positive for a condition called neurocardiogenic syncope - accounting for the fainting episode that started all of this.
Neurocardiogenic syncope (as explained to me) is a condition where the body responds to certain situations where it should be increasing heart rate and blood pressure by instead decreasing them. This causes a loss of blood to the brain ultimately leading to unconciousness. It can be controlled by lifestyle changes or (in severe cases) by medication. Seeing as how this doesn't happen to me very often, I think I'm going to try the first option.
Since there seems to be some interest in the mkvcd script (I get a couple of hits per day on it) I've made some enhancements - the new version doesn't require subprocess and should therefore work on out of the box on pre-2.4 versions of Python.
In other news, I'm going on my fifth week at the new job. I must say, I greatly preferred unemployment (except for the not-getting-payed part). I've been charged with the task of essentially managing the last phase of part of the project for a guy who has gone away for about a month. This mainly involves getting people who should have been involved in the project months ago to sign off on it so we can start running it in production next week. Last Wednesday when I got home I was too tired to speak. I hope this situation improves.
The one thing that's keeping me going is my latest addiction - hacking OpenGL! I was playing around with Blender a month or so ago and started getting frustrated with the game engine, so I decided to try writing my own. At this point I have a little single-level maze-like world that I can wander around FPS style. I'm currently working on a good C++ serialization mechanism so I can build a dedicated server for it. It would be fun to get some other people involved in it - drop me a line if you're interested. There's lots to be done. I'll put the source code online shortly.
Today was the day for my follow-up appointment with the cardiologist. About two weeks ago, I had an echocardiogram and walked around for a day with a Holter monitor. Today I went to get the results.
And the tests showed... nothing. I can't say I was terribly surprised, but I must confess I was a little relieved. No indications of irrhythmia or any other heart issues. The doctor felt this ruled out the more serious possibilities.
She was a little concerned that I might have a condition called Neuro-cardiogenic Syncope - which I guess is a problem where, in certain situations, the normal reflex that increases heart rate and blood pressure is reversed. Her office is supposed to contact me to schedule a tilt-table test to check for this.
Apparently there are medications that can help with this condition, but I don't think I'd be willing to start using them. It's not a life threatening condition, and it's not as though I'm passing out regularly. Why would I want to change my life and start taking medication to prevent it? I'm starting to wonder whether I even want to go ahead with the test, although I suppose it would be nice to know.
All good things got to come to an end, and that includes unemployment. I just started on a new job at Wachovia today. I'm back to working through the company I co-founded, Enduden Consulting. I got the job through Open Systems Technology - I had a very good experience with them and I'd highly recommend them, particularly Glenn Lavender.
Anyway, Wachovia is looking to be a sweet gig. Right next to Grand Central (for now), lots of very smart people on my team, business-casual attire, and a good rate with no "professional day" cap. So I'm not terribly bummed out about being employed again...
I just got back from New Hampshire. My hiking buddies and I just completed what for us is a new high-water mark in our campaign in the Whites: a winter hike up Mt. Jackson!
In addition to the normal problems of hiking in this region (mainly the endurance required and the need for the right clothes and enough water) winter hiking presents the additional hurdles of difficult navigation and extremely cold temperatures. When we got out of the cars at the trailhead, the outside temperature was already in the single digits, with heavy winds taking the windchill well below zero.
I've been burning a lot of VCDs (Video CDs) lately so I can watch videos on our TV instead of in front of a computer. The process is very straightforward, but also very detailed, so I've written a little python script that manages all of the details.
The script is called mkvcd. It requires MPlayer (specifically, mencoder), vcdimager, and cdrdao. Newer versions of cdrecord (which support "Disk at Once" writing) should also be usable, but will require more extensive modification of my script.
You'll need to modify the variables at the top of the script to identify the locations of these programs and the parameters for CD recording. You'll also need a fairly recent version of python - 2.4. Earlier versions should work, but you'll need to install the subprocess module (no guarantees on whether the module I've linked to is the same as the one in Python, let me know if it's not).
The upshot of all this is that I can now burn a VCD from a set of arbitrary video files like so:
mkvcd video-1.avi video-2.mpg
I went down to Manhattan yesterday for two interviews, both financial firms that I will not name here. I was a little leary about scheduling a morning interview as this meant getting up about four hours earlier than I am used to these days and then having to act intelligent in front of any number of inquisitors. On the other hand, one trip to the city to do two interviews seemed preferrable to two trips to the city to do one interview each, so I took a crack at it.
Yesterday, for a change, I went to the Hudson Valley Hospital emergency room. No, there's nothing seriously wrong with me. But I did pass out a couple of times and Jenny insisted that I go.
Since I seemed to be between programming activities, I decided last night to take another swing at getting Doom 3 up and running on my laptop. I downloaded the latest and greatest ATI Fire GL drivers and started it up... and it died with a seg-fault.
Jenny and I just got back from our honeymoon. We went to Hawaii for three weeks - one week on Kaua'i, two on the Big Island. It was great.
I blogged the entire trip, you can read all about it here.
Happy Solstice, everyone! Every year on this day, I resolve that next winter Solstice will be the one that I'm actually going to do something signficant to celebrate. And this year is no exception.
For the past few days, my company's web server enduden.com (which, among other things, hosts this site) has been unresponsive. The details of our current hosting situation hampered my ability to investigate this issue, but it turns out that the problem was due to our business class IP address getting yanked out from under us. Thank you, Comcast.
I've updated our DNS entries, and hopefully will be moving this site over to a new home real soon. We apologize for the inconvenience...
"We will release no software before it's time" - NOT!! I've found a few minor bugs in SpugSpam 1.1 so I just now released version 1.1.1. Enjoy!
SpugSpam 1.1 has been released. I highly recommend that anyone using this package upgrade - it's only new feature is the addition of an SPF check.
I recently quit Bloomberg due to irreconcilable differences. I'm going to chill out and enjoy joblessness for a while and take my time looking for the next thing.
All of this free time is a great opportunity for me to work on my own projects - I've made some enhancements to spugnews and released version 1.1.
I've also had some changes for spugspam that I've been testing for a while now, mainly the long awaited Sender Policy Framework check. Hoping to get this out any day now.
Yesterday I was touring the various houseware stores in my area trying to find a free-standing air conditioner, when I decided to stop by Electronics Boutique and take care of something that I have been putting off for way too long - buying Doom 3! It was on sale for $15.
I got it home, hoping that the Linux installer would be bundled with it - it wasn't. No matter, the download instructions were easy enough. So after runnning the installer and copying the gig-and-a-half of game files from the installer, I started up the game and... Segmentation fault. So I think I know what I'm going to be doing for the next few days. Glad it was only $15.
A problem at work caused me to have to do some heavy-duty Javascript coding. It's an interesting language, a lot more powerful than I had originally thought. It got me started thinking about ways of adding more sophisticated scoping constructs to it, which resulted in my writing this module and this article.
Enjoy.
I am pleased to announce that our wedding website is now online. Check there for updates on our "big day" which is approaching more quickly than I'd like...
On another note, someone just pointed out the existence of a utility which solves a problem that I've had for a while now - integrating my laptop and desktop computing environments, so that I can work on both when I'm at home without having to switch keyboards. The utility is called x2x, and it forwards keyboard and mouse events to a different X server. You can set it up so that you can move your mouse right onto the other desktop. It's very cool, check it out.
My 7 year old Toshiba laptop was starting to act a little funny, so last mongth I finally went and bought myself a new laptop. It's an IBM Thinkpad R52, you can read all about my adventures getting Linux running on it here.
Everything is changing faster than I can describe. For one thing, I am pleased to announce that I have recently proposed to my long-time girlfriend and she has accepted. More on this later.
On another note, I have just released spugspam 1.0.1. This release fixes a rather serious bug - analysis of subject line confirmation strings didn't work if the "from" header followed the subject. Seems to be all better now.
I spent a little quality time with this site this morning (and last weekend, too) in the interests of distributing a new version of spuglib. My test/distribution mechanism is a little bit cleaner now, and I think that there's nothing actually broken anymore.
Happy Thanksgiving! I was messing around with this new song, recording a version to teach it to my band. It's still kinda rough (a few screw-ups here and there), but sounds pretty good! Check it out.
These days I've been back to work on my audio software package. I added a new file format, and I've started adding a synthesizer system to it, which has led me back to the problem of automatically generating python bindings... Have to publish it some time soon.
I'm pleased to announce the release of my latest open source offering: the SpugSpam confirm-response mail filter. It's a lot like ASK, but better suited to use with procmail. It has solved my spam problem, at least for the time being.
Ahhh. Springtime. Time to try to attempt to reclaim our lawn from Mother Nature. So far, Mom is winning. Oh well. This is really our first attempt at having a lawn, and ours is not the most lawn-friendly of lots, so I expect it will be a few years before we get this down. And if it ends up being too much work, screw it. We'll just let half of it turn back into woods.
I finally sat down and tried to improve upon the crappy way that IE rendered this site, and I think I'm almost there. I hope all you Windows users out there appreciate my efforts.
Argh. 3 months without an update. Guess I'm not much of a blogger.
After almost 25 years of playing guitar with no effects other than the occassional distortion, I finally broke down last week and bought the Digitech RP300A "Modelling Guitar Processor". It comes with 40 presets to allow you to sound like all of the current heavy metal guitarists, which is rather annoying. However, it does let you define your own effects pipelines, and it comes with a full battery of effects. So I figure it's better than buying the 10 or so pedals that it replaces, especially since I'm relatively new to this world and know very little about it.
I put together a sample of me fooling around with it - it's not very good, musically, but it does give you an idea of some of what you can do with the pedal. I overlayed two tracks, lead and rhythm, but other than the mixing everything was from the processor (including the auto-drummer :-).
Ok, certain days I shouldn't be trusted with sharp instruments, and I guess this is one of them.
Since I let my cloud9.net account expire, I've had to move my software pages onto this site.
Of course, the project pages have not yet been ported to spugweb, so I basically had to set up some rsync scripts to install all of the old stuff into my new tree...
So the bottom line is, I think it's mostly all there, except now the contents of my software page have suddenly disappeared! So I apologize for this, and any remaining liks to cloud9.net. Hopefully I'll get around to dealing with all of this this week.
It's about time I got around to updating this page.
After a lengthy job search, I finally started work at Bloomberg in Manhattan two weeks ago on the 18th. The days are pretty long and I spend about 3 hours commuting, so I haven't been online much :-(. However, I do bring my laptop with me, so I have been getting a lot done on the train. I should have some new stuff available soon.
I've been informed that this page doesn't render very well under IE. Hopefully I'll get around to fixing that soon. In the meantime, I apologize to all you IE users, and recommend that you get a browser with working CSS support.
I've added the beginnings of dependency timestamp tracking to spugweb (this will ultimately allow all cached nodes to be regenerated properly when anything affecting them changes)
I'm currently working towards a user/session management system that will be applied to the Enduden timesheet tracking system. It will be fairly flexible, so it should be usable for any kind of user tracking. I'll probably use it as the basis of a mailing list manager, too.
I just made a bunch of cosmetic changes, mostly so that the site looks sane under older browsers that can't deal with the latest in style sheets. Haven't tested under IE yet, though...
Welcome to my new homepage! I now have enough of my website ported over to spugweb to publish it. It's still largely under construction. I'll post regular updates as I continue to modify it.