Round and Round They Go! Where They'll Stop, Monty Knows! Over the weekend the twitterwebs lit up with the #savemysql tag in response to a plea from Monty, the founder of MySQL. The basic gist of Monty’s plea are as follows: MySQL is a critical piece of infrastructure Thousands of businesses use MySQL in functions beyond the web Oracle sells a variety of competing databases Oracle doesn’t have the best track record with Open Source Therefore, Oracle should have to make a set of promises related to the commercial viability of MySQL.
Since I started on my “seekrit project” I’ve asked a few questions on programming related topics at StackOverflow. Thus far I’ve found the answers to be really helpful. While most people know about StackOverflow, lots of folks don’t realize that there three other sites in StackOverflow empire: ServerFault - for system administration issues, SuperUser - for end user software issues, and Meta.StackOverflow - for site related questions about StackOverflow. The Four Horsemen of the StackOverflow Empire
For a new secret project I’ve been putting together an installation of Trac to provide a web interface for task management. I found myself wanting to create a nice looking table within a Trac wiki page to document different dependencies needed by the software. In a normal installation there are three different ways to do this: Trac’s Wiki Formatting This is probably the simplest option, however it’s also the most limiting, there is no way to provide additional styling to elements and you can’t create columns that span multiple rows or columns.
Several years ago I created a nifty little photo gallery webapp for F-Spot users called PennAve. PennAve was designed to be incredibly simple in its use: Tag a set a photos in F-Spot as “Public”, copy the database to your web server, and boom, those photos would be displayed. It was quite simple and just worked, well for the most part. However, in the design of PennAve I made a couple of critical errors and since that point the marketplace has changed significantly.
This past weekend I left New York City and traveled to Columbus, OH for Ohio LinuxFest 2009 (OLF). Unlike many shows, such as LinuxCon and the now defunct OpenSourceWorld, OLF is entirely community run. That means you’ll notice a couple of different things: it’s much cheaper, there’s a wider range of attendees, and while many top name speakers attend, you’ll also get a smattering of other folks making their debuts on the conference circuit.
The Free Software Foundation has, rightfully in most cases, alerted computer and technology users to the problem of “antifeatures“. Briefly, an antifeature is when a program does something to offer a lesser experience that took significant effort to accomplish. Often times antifeatures are used as differentiating elements between different versions of a product. When you buy the lesser version everything is still there, it’s just that there is a small amount of code that disables part of program.
It’s no secret that almost all software has bugs. Even if you are lucky enough to understand how to formally verify a program, odds are that it won’t work for your program. It’s just far too difficult. Rather than eliminate all bugs, which is next to impossible to do, software engineers have sought ways to minimize the number of bugs present in a system and ensure timely responses when bugs are discovered in the field.
After obtaining a new laptop one of the first things I always do is to make an image of the primary hard drive. I then copy this image to another computer with a lot of hard disk space and leave it there as a backup should something ever go really wrong with the laptop. There are a variety of tools both commercial and Open Source that make this process relatively easy.
I’m officially on the hook for competing in Iron April 2009. It’s an interesting event organized by a real Ironman, Kevin Haugh, that takes loads of folks who normally don’t triathalons and convinces them to do the distance of an Ironman over the course of the month of April. It’s an informal sort of competition where you’re motivated by the other folks who are also trying to accomplish the same thing.
As I mentioned in my previous article about using a Drobo as primary MythTV storage, the optimal solution for using a Drobo in MythTV is to record to an internal hard drive and then migrate the recordings later to the Drobo. When migrating recordings care is required because the recording could be in use, either as a result of someone watching the recording or because transcode/commercial flagging jobs are running on the recording.