This is from May of 2012...

http://avyupdates.blogspot.com/2012/05/iphone-avy-beacon-app-jokes-on-you.html

Avalanche beacons definitely help. And the technology has dramatically improved in the last twenty or thirty years. They are definitely easier to use and much more reliable nowadays.

Having said that, there are some fairly serious limitations on how well they can work. From what I remember of avalanche school, about fifty percent of avalanche victims die of traumatic injuries during the event, so obviously beacons can't help in those situations (my own personal experience in an avalanche included the tail of my ski hitting me in the forehead while still attached to my boot). But for the remaining fifty percent of victims who are likely to suffocate within minutes unless found avalanche beacons are an invaluable tool.

There is, of course, much that can be done to improve them. But that is another story.

Linux vs Hurd vs *BSD

Gnome vs KDE

MySQL vs PostgresSQL

Ruby vs Python ... and any rant that complains that some piece of software isn't really "free" because it doesn't use the ranters favorite license.

Having done a few contracts for the feds over the years, I have a pretty good idea why something like this happened.

Probably the biggest one was standards chosen before the project was even conceived and shoehorned into some product it wasn't intended for.

With the NSF, it was using Ada and ISO/OSI instead of C or C++ and TCP/IP. We solved that problem with creative prevarication. Since there was no imaginable way that the functionality was even implementable in ISO/OSI, we got away with it.

With DOI, it was using IIS and Windows rather than Linux and Apache. We told them that would increase development costs by a factor of ten and delivery would take twice as long. A waiver was quickly produced that let us do things our way.

It tells you how awful the federal contracting system is if you have to lie or bully them to let you deliver a working product.

Their claims that "an intern did this" on their twitter feed are a laughable, bald-faced lie.

No intern would be able to independently put together a marketing campaign like that, complete with video.

In general, whether your grain of choice is wheat, rice, barley, maize, or quinoa, you'll need to cook it. And you won't necessarily need pottery to cook it either. Lots of native american cultures cooked in baskets, by transferring hot stones to the baskets which were full of liquid. This amazingly didn't burn the basket.

Chances are this was how our distant ancestors cooked their grains. While pottery surfaced in Japan about 9000 years ago, it took quite a while to disperse.

So a similar thing could obviously be done with beer, and the beer could easily be stored in watertight baskets, and wouldn't exactly leave a whole lot of evidence for the archaeologists.

And before you ask about watertight baskets, I have an Eyak basket made of seal gut which is quite watertight. Anyway, you could always seal the basket with animal fat.

I have to ask, aren't there things (in space) that have a higher return on investment? A ballpark figure for a moon colony would be well north of $200 billion.

It seems that the science return from unmanned space probes has been enormously high, and it doesn't seem clear that the science return from manned space travel has been all that high. I'd also worry that the resources spent on a lunar colony would be taken from other space programs, like the unmanned exploration programs. So we'd be trading a high-return program for a somewhat lower one.

I'd also argue that if we want to build a long-term presence in space, focusing on technologies that will let us have sustainable, affordable space travel would be a wiser way to go -- I'd rather see a moon colony in 2050 or so that was permanent and affordable rather than one in 2020 that was abandoned in 2022.

The classic book Peopleware had some excellent disussions about this issue. Like most productivity-related things, there is good news and bad news.

There is an excellent discussion in that book about how productivity of coders is impacted by the number and frequency of distractions. That helps your case.

On the other side, there was another great discussion about listening to music while programming. They referred to a study (at MIT, I think) where two groups were given a series of puzzles to solve. One group while listening to music, the other while not listening to music. Here's the rub: all of the puzzles had a "brute force" solution and a much simpler "aha!" solution. None of the people listening to music found the "aha!" solutions, and about half of the people not listening to music did. Now depending on your situation and the kind of code you are writing, you might want or need those "aha!" solutions and probably ought to skip the music.

Let's see, the big news stories this week: (1) Tiger Woods gets in a fender bender after he gets in a fight with his wife, and (2) the White House party crashers apparently lied about other stuff, too.

Journalism is already dead.