Sleeping Bags for Backpacking

Some friends and I have been talking about going on a multi-day backpacking trip (first one will likely be an "easy" trip, where we'll almost be able to drive up to the camp site, just to test everything out, etc). Most of us don't have the proper equipment (anymore) and things have changed a lot since the last time (in my boy scout days, oh-so-long ago) I've been out on a multi-day camping trip (never really done the backpacking thing before), so I've been doing a bit of research.

First and foremost, I knew I'd need a sleeping bag so the first step was deciding what kind of temperature rating I'd need my bag to meet. Did a bit of reading and discovered that starting this year, most sleeping bag makers in the US have switched over to the European standard for rating sleeping bags. This was comforting news (hah, bad joke) in that comparing sleeping bag temperature ratings would be a lot more like comparing apples to apples (previously each manufacturer had their own method of measuring this, so comparing bags from different makers was impossible to do).

Since my friends and I will likely be sticking to the North East, and probably in the late-spring to early-fall time frame, I estimated that I wouldn't want a bag rated for anything warmer than 30 degrees. Even in mid-summer, the North East can get down to the low 50's and so a 40-degree bag would barely be warm enough. Note that the temperature rating on a sleeping bag is often the "survivability" rating as opposed to the "comfort" rating, and I prefer to be comfortable! Since I'm prepping for the possibility of backpacking trips in the spring and fall as well, I figured a 20-degree bag would be a safer bet.

Next, I had to decide on the type of filling so I read up on the difference between synthetic and down filling. To sum up, here's what I learned:

• Down is often lighter, especially the higher the fill rating (e.g. you might see things like 650-fill or 800-fill - the higher the fill rating, the less down you need to occupy the same space, resulting in a lighter weight bag).
• For down-filled sleeping bags, duck vs goose doesn't really matter, what matters is the fill rating.
• For damp environments, synthetic is often a better choice because synthetic-filled sleeping bags only lose 15% of their effective warmth when wet, while down-filled would lose 100%.

I wanted to keep my expenses below $200 if I could, so with that in mind I did some searching to find some sleeping bags in that price range with good reviews and I came up with the following bags:

• Down: Kelty Light Year 20-Degree Sleeping Bag
• Synthetic: The North Face Cat's Meow 20-Degree Sleeping Bag

Both bags were very highly rated in various magazines and online reviews that I had seen and both were around $160 for the Regular size (up to 6') and $170 for Long (fitting up to 6'6", which is what I needed). There are some cheaper bags, but most of them aren't as lightweight (under 3 lbs!) as either of these 2 bags and/or they didn't get as good a review (or didn't have any review that I could find). If you want cheap, you could go to Walmart and find sleeping bags for as cheap as $10, but I'm not sure I personally trust that any of those bags will be a good long-term investment. Maybe I've just been bitten once too many times by the lure of the uber-cheap.

In the end, I decided to go with the Kelty Light Year as it was a little lighter (4 oz) and packed a little smaller. While the dampness drawback did/does concern me a little, there are easy ways around that. Wrapping your sleeping bag in a plastic (or otherwise waterproof) bag while it is packed away in your backpack and not pulling it out until it is inside the tent should suffice in preventing it from getting wet, even if you have to pitch your tent in the rain.

Re: Red Hat, 16%. Canonical, 1%.

While some people are busy complaining that Canonical doesn't contribute as much as others, I'd like for everyone to take a step back and ask themselves, "what would Gunny say?"

I'll tell you what he'd say. He'd say,

Hmm, that's interesting. Do you know what makes me sad? YOU DO! Maybe we should chug on over to mamby-pamby land where maybe we can find some self-confidence for you, you jack-wagon! Want a tissue?

After he finished ripping someone a new one, he'd point out that in that very same GNOME Census slide deck, I am ranked #8 in the top contributors list and I haven't contributed much of anything to any of the core GNOME components in about 5 years.

Yeah, that's right you cry babies, I put all y'all to shame.

On a more serious note, for better or worse, we all knew what we were getting into when we decided to take up the Free Software baton and start running with it. This is just how Free Software works. Don't like it? Cry me a river.

tl;dr

Update: It seems my post here has been misinterpreted. Allow me to try and rectify this. I'm not pissed off at Greg for voicing his opinion. We all do it. I'm just making a mockery of the whole situation because I was itching to trollcat and because I wanted to pat myself on the back for being #8 on the individual contributors list in terms of commits (as meaningless as that is). Also because I was up late last night and saw that Geico commercial with R. Lee Ermey which just cracks me up every time I see it.

Early Morning Sunrays

IMG_1886, originally uploaded by jstedfast.

Took this photograph around 6:30 in the morning on June 18th. The way the sunlight could be seen streaking through the trees and the complete stillness of the water was surreal, so I had to take a photograph of it ;-)

Dawns of June

Dawn at Wollaston Beach, MA on June 4th.



Dawn at Core Creek Park in Bucks County, PA on June 7th.



Dawn at Milton Pond, NH on June 17th.



Dawn at Milton Pond, NH on June 17th.

Reflecting on 10 Years at Ximian

IMG_1047, originally uploaded by jstedfast.

Today marks my 10th anniversary since I was hired at Helix Code to work on Evolution.

In that time I've gotten to work closely with and learn from some of the most talented developers in the Free Software community including Michael Zucchi, Miguel de Icaza, Federico Mena-Quintero, Chris Toshok, Larry Ewing, Michael Meeks, Dan Winship, Radek Doulik, Joe Shaw, Vlad Vukićević, Dave Camp, Dan Mills, and many others (too many to name!).

Back in the early days of Helix Code/Ximian, we all worked tirelessly to put together the very best GNOME distribution we could and make Evolution the very best groupware client we could.

We had big dreams and I like to think we succeeded. GNOME has become mainstream and the Linux Desktop can most definitely be measured as a success.

Of course, we couldn't have done it without all the help and hard work from the entire GNOME community.

Today, a younger generation of hackers are taking up the reigns to make GNOME awesome with things like the Paper Cuts project by David Siegel's team at Canonical and the work being done by Red Hat on the new GNOME-Shell.

I'm still working with a couple of my old Evolution teammates like Larry Ewing and Chris Toshok on the Moonlight project in the hopes of making it possible for Linux Desktop users to view Silverlight content on the web. We've been making great progress with implementing Silverlight 3.0 and 4.0 features in svn and I've got some accomplishments on that front that I should really blog about but I've just been so busy.

Much love to all you GNOMEies and thanks for all the support and love over the past decade!

Sundown over the Charles River

IMG_1022, originally uploaded by jstedfast.

Weird bugs due to gcc 4.4 and strict aliasing

I was just running the unit tests for GMime and I got a couple of failures on my openSUSE 11.2 machine that I have never gotten before. I started debugging and I noticed something very odd. One of my functions that returned a linked-list of 'word' tokens was returning NULL for something that it should not be returning NULL from, especially since I had just stepped through that method and seen with my own eyes that it was creating and appending nodes to my linked list as it should!

At this point I split out a tiny test case:

#include <stdio.h>
#include <stdlib.h>

typedef struct _node {
    struct _node *next;
    int value;
} Node;

int main (int argc, char **argv)
{
    Node *list, *node, *tail;
    int i;
    
    list = NULL;
    tail = (Node *) &list;
    
    for (i = 0; i < 10; i++) {
        node = malloc (sizeof (Node));
        node->next = NULL;
        node->value = i;
        
        tail->next = node;
        tail = node;
    }
    
    if (list == NULL)
        printf ("oops, list is null???\n");
    
    return 0;
}

I then built this test program using gcc -Wall -g -o list-test list-test.c. When I ran the program, no error.

Huh.

Luckily I thought to rebuild with -O2. This time when I ran my test program, it printed out the error I expected. The list was NULL.

Doing a bit of research suggests that gcc 4.4 has decided to enforce strict aliasing for -O2 and higher, which explains why it works without -O2.

Oddly enough, I get no strict aliasing warnings from gcc even when I use -Wall -O2.

So be warned... gcc 4.4 may break your perfectly valid code in mysterious ways.

Update: Looks like MySQL had similar problems and according to this article, it is suggested that the gcc developers have interpreted the c99 specification far too strictly.

Update 2: Josh's comment had an excellent explanation of the problem this code hits, so I thought I'd add it to my blog post for anyone who may otherwise miss his comment:

I imagine that gcc's aliasing thinks that dereferencing a Node* can only write to Node objects, so it won't have any effect on Node*s like list. Thus it thinks that list is never modified in that function, and it propagates the NULL constant throughout.

I also liked Josh's explanation of why the above code works (since a number of people have been confused by it already, I'll post that too):

The only reason it "works" in the -O0 case is because the next field happens to be the first field, as Fabian pointed out. The first time you write to tail->next, you're writing to &list with no offset, so list happens to get the value of node. When next does have an offset, then the value of list is not changed, but something else on the stack after it will be clobbered.