Moved again

S and I spend last Wednesday, Thursday, Friday, and Saturday moving. We had lots of help from many places (thanks!) and overall the move went pretty smoothly. Now we have some minor issues like we own no pots and pans so we can't cook; our stuff is still packed and all over the place; and we don't have much food to eat.

I've done 10 furniture-moves in the last 7 years. I've done a bunch of non-furniture moves (mostly between corporate apartments when I was doing consulting) as well--but those only involved one or two carloads for each move.

If you're waiting on me to get something done, know that it's in the queue but it's going to take me a week or two to get a critical mass of stuff unpacked so I can continue regular activities again.

"Why I Hate Advocacy"

I discovered Why I hate Advocacy from jgoerzen

I encounter this regularly when talking about operating systems, programming languages, text editors, and even non-technical things like car manufacturers, methods for making coffee, types of beer, music, politics, .... I never connected it with a "want to be part of the tribe" behavior. I wonder if this behavior is something that's relatively recent or dates back to primitive man. Regardless, it makes it difficult to discuss things in a rational, objective manner to understand what's really going on and the nuances involved.

Also on jgoerzen's blog entry is a link to Why smart people defend bad ideas. Reading the two essays back to back was really funky.

PyBlosxom 1.2.1 released

This is a minor bugfix for PyBlosxom 1.2. If you use the conditionalhttp plugin, you'll want to upgrade. Otherwise, it's not crucial.

Changes:

  • Fixed a problem where the blosxom renderer never c hecked to see if it had already rendered the page. This affects the conditionalhttp plugin, but not much else.

  • Removed an extra filestat.

  • Added a setTimeLazy method to the FileEntry class.

Testing in PyBlosxom

Doug was going to do a unit testing or a regression testing or some kind of testing system in PyBlosxom so that we'd have testing and wouldn't have to do the manual testing and the "well, gee, it must work because I don't think I did anything wrong" [1] type testing. But then he ran out of time or interest or something. That time period of PyBlosxom development was a little rough for all of us.

Anyhow, I bumped into this blog entry on Functional testing in Paste which at first blush looks fantastically awesome for testing PyBlosxom stuff. It's based on testing applications with Paste.

I'm tossing this in the blog in case anyone is interested in working on fleshing this possibility out or in case I discover some free time with nothing to do.

Updates:

06/01/2005: Added a necessary footnote.

The d20 DIEt

I figured I'd join the diet fad and present my 100%-satisfaction-guaranteed best-results-ever fad diet. I hope to make a million dollars selling copious amounts of totally non-relevant diet materials and possibly confusing people in regards to the basics of nutrition using highly ambiguous terms and gross misrepresentations of how things work. I will then give those million dollars over to various charities and studies seeking to help people fix their confidence, self-image, and alleviate the ill-effects psychological or otherwise of obesity.

This diet is a little different since it's not really a diet but rather a DIEt. See, it's the d20 DIEt. It's better than sliced bread. You'll lose the weight you should be losing rather than the weight you think you want to lose.

This weblog entry summarizes the diet rather than goes into long-form. I'm saving that for my soon-to-be-best-selling book about the DIEt.

step 1: figure out what character class you are

You start by figuring out what character class you want to be. Pick up a Player's Handbook v.3.0 or v.3.5 and pick your favorite character class. The class you choose affects how aggressive you are about your DIEt. Classes that have initally poor Will saves will be less aggressive than classes that have hefty Will saves. Everyone starts at level 1 of their chosen character class.

step 2: how it works

Everyone is allowed to eat three meals a day consisting of an appropriate amount of appropriate food sans dessert, chips, appetizers and such. They make will checks for everything else with the following DCs:

what

DC

between-meal snack

10

after-dinner snack

15

dessert

15

chips/appetizers

15

If you miss your Will check (i.e. you can't help yourself), then you get to eat the thing mentioned. If you make your Will check (i.e. your will prevails), then you don't eat it. Period.

You don't get to make multiple Will checks for the same thing. If you make your Will check for dessert, then you don't get to have dessert. You don't get to make a Will check for a brownie and another for a cookie and another for jello... ad infinitum.

Everyone starts their DIEt on a Sunday morning. Every sunday, you go up a level. Check the Player's Handbook to see what your new Will value is.

Over time, you'll reach such a high level that you'll be making all your Will checks and then you won't be eating anything.

As with all diets, you have to be serious and not screw around thus deceiving yourself into lapsing.

The effective part of this diet is that it's a roll of the dice so you don't have to dictate your own fate.

advanced rules

You can try subclassing, dual-classing or whatever provided that you strictly follow character class rules in the Player's Handbook.

You can have someone else roll the dice for you.

You can use one of those dice-rolling programs available on a Palm Pilot or other handheld device.

thanks and such

I'd like to thank my D&D mates and my co-worker for helping to revise the DIEt to its current form. I hope they in turn make a million dollars for their kindness.

Choppy video

I have a Canon PowerShot S230 Digital Elph camera which has the almighty power to record video in some encoding with AVI format. Playing these videos works fine under Windows XP with Windows Media Player. However, I had a heck of a time trying to get it to work with either MPlayer (as it's distributed by Ubuntu Hoary) or Totem (as it's distributed by Ubuntu Hoary). With MPlayer, I'd get some incomprehensible error, then MPlayer would tell me to re-compile with the debugging information and try it again, then die. Totem (the one with the gstreamer backend) would play it, but it'd be really weird and choppy.

As a side note, in case this is useful to anyone, I have a system with an AMD64-3200+, 1 GB of RAM, and various other exciting quantities of exciting things running a mostly stock Ubuntu 05.04 though I am pulling packages out of the universe. This wouldn't be much of an issue given that I've got a machine running Windows XP with Windows Media Player except that I'm switching my world over to run exclusively on GNU/Linux and Open Source applications.

So armed with my observations, I did some poking around to at least get a handle on what the pieces involved were. After 15 minutes of googling, I found nothing that seemed to help. However, I did discover that there's a version of Totem with a xine backend in the Ubuntu repositories. So on a whim, I switched from the gstreamer Totem to the xine one.

Now the video works fine. I figured I'd post this even though the details I've written down couldn't be any less defined.

Spearmint status: 05-29-2005

Due to various miscalculations and misunderstandings, we left the spearmint in its tiny little pot outside during the winter and it appears to have expired.

However, S and I are moving in a couple of weeks and we're going to try again! This time, though, we'll get a plant that has more use to us.

SourceForge is not a good indicator of the success of Open Source

I keep seeing articles and quotes where people in total ignorance state that Open Source is dying and then they turn and point at the number of dead projects on SourceForge to back up their ridiculous claims.

Quick note, I'm going to use the term "Open Source" in that silly loosey-goosey way many "journalists" in the media use it. Otherwise this mini-article looses its oomph while I do vocabulary translation.

There are a lot of dead projects on SourceForge and I think the number has nothing to do with the present and future of Open Source as a method of developing software or as a classification of software.

First off, some projects die before they leave the gates. There are dozens of projects on SourceForge where the mission statement is something like "We're out to build the most technologically advanced 3d rendering system EVAH!" Many of these projects will go no where because they're not realistic. I would posit the people who created these projects are either inexperienced in the subject at hand, they're eternal dreamers, or they don't really know what it is they want to do in the first place. There's nothing wrong with that--most of the developers I know cut our teeth on things like this and learned valuable lessons as to what ideas we have that are worth tackling and putting the energy into and what need some more time to be fleshed out.

This happens all the time in non-Open-Source projects. Watching any software company's press releases over time alone shows that some projects are good ideas and some don't make it past the gates.

Second, some projects lack the infrastructure and management to survive. Most of the projects I've worked on are dangerously close to this line. Every project that is successful has a huge amount of development and user infrastructure there to facilitate communication, testing, bug-finding, documentation, and a slew of other things that healthy projects need. Why do projects need these things? They make it possible for a diverse group of people to work on the project and communicate with each other. They make it possible for users to look at the project, figure out if it fits their needs, install, configure, use the software, and report issues back to the development team. Without this infrastructure in place, it takes a huge amount of energy to keep things running and unless people are working on the project full-time, it's likely people don't have time to pull that off. I would posit this is the biggest issues for small and medium Open Source projects. Building infrastructure and policies is hard work and it really requires the people involved to have a lot of experience in this sort of thing.

This is true of many things--wood-working projects, making movies, starting up a band, starting a restaurant... What is the success rate for bands? How many fail or disband after a few months? Does that mean that music is dead or failing?

Third, some projects are abandoned because similar projects end up being better in some way: features, management, infrastructure, momentum, marketing, etc....

This happens in non-Open-Source projects all the time. When was the last time you heard of someone using Lotus 1-2-3 or VisiCalc?

While not comprehensive, I think these three reasons cover a huge number of failed/dead/abandoned SourceForge projects.

This isn't a scientific study. My experiences with Open Source software has led me to believe it's totally ridiculous that people point at the failed projects on SourceForge and use that to base their ridiculous claims that Open Source is a fad and/or that it's a failed model and/or that it's going to die.

Tech support

A friend of mine just said:

Some day, you'll have kids... doing tech support is like talking to 5 year olds about anything... you never get a concise answer, nor one that makes sense.

Great. I can't wait.

5/25/2005: pyblosxom development status

I'm going to try to fix a couple of issues before releasing PyBlosxom 1.2.1 and contributed plugins pack 1.2.2. The issues are as follows:

I'm working on PyBlosxom Manual changes as well. I think it's good to add a chapter on comments and I need to flesh out the chapter on syndication, too. If anyone wants to help with the PyBlosxom Manual, let me know--I'm happy to pass off some of the writing/collection/verification work to other people.

If you find any problems with PyBlosxom 1.2 or the contributed plugins pack--let me know those issues as well.