LonnieOlson

Last Sunday I had the chance to go to the Wyoming Downs. I’ve never been to a horse race before. My only experience was that of dramatized scenes in movies. It was quite interesting to see how accurate horse racing’s depiction in movies really is.

Besides getting a bit sunburned, I had a great time. Luckily I went with a friend that could give me a quick tutorial on how to place bets. Once I got the basics down, it became quite easy. Most bets are really straight forward. It was really interesting to see how even the best horses could get out run. When an unexpected horse wins people often lose big or win really big.

No matter how much analyzing one does, the element of chance is still the primary driving force in every race. Long shots are possible.

As long as you are careful, and bet modestly, the level of fun and entertainment will always outstrip the losses you will have. I highly suggest a trip to the races to everyone, and bring your family too.

After reading all the details about the “new” DNS exploit I feel quite annoyed. These types of attacks have always been possible. This isn’t new. Cache Poisoning has always been on every DNS server administrator’s check list of things to carefully plan to prevent. I compare it to Firewalls: Every firewall administrator knows that best practice is to block everything by default and only make exceptions for what should be allowed.

This idea has been around for well over a decade. Maintaining a discrete list of what is allowed which can be completely enumerated with a great level of confidence and block the rest. Badness cannot be enumerated completely. Blacklists will always be missing important aspects. Expecting that all people are good and don’t do bad things will always turn bad.

Patches released for DNS services that are vulnerable do not fix the root cause. It can’t be fixed because it is part of the original specification and migrating away from it will be equally as painful as the migration to IPv6 is. These patches only implement other kinds of mitigation for the exploit. The best form of mitigation comes in the form of implementing standard best practices that have been around for many years.

DNS servers should carefully control who is allowed to ask questions about non-authoritative zones (recursion). DNS servers at ISPs should limit recursion to customers only. Corporations should run internal recursive DNS servers with access restricted to internal users only. This will severely isolate any damage caused by cache poisoning.

I am not saying nobody needs to patch their servers. In fact the patches should be applied quickly because it does help quite a bit. I am just saying that if you have already implemented best practices you shouldn’t have to worry very badly. And if you haven’t implemented them, do it now!

After reading through CrackBerry’s Top 10 Reasons Why the iPhone is NO BlackBerry I thought I should compare it to my situation.

I really like my AT&T BlackBerry 8820 a whole lot. I really hate Windows Mobile devices, and dislike the Treo line. But I still want an iPhone really badly. This article makes it sound like BlackBerrys are better. I disagree.

10. The iPhone’s Not Designed for One-Handed Operation

Duh, I call this a feature, not a problem. Even when I am not driving, I still hate typing with one hand. I could care less.

9. Every iPhone is Created Equally–At Least on the Outside

Again, so what. The one model of iPhone is the model I would want.

8. No Removable Battery, No Backup Power Supply for the iPhone

Based on my BlackBerry usage, the removable battery is completely unnecessary. I generally only charge it once every 2 - 3 days. I have never replaced a battery on a cell phone ever. I usually replace the phone before the battery dies. Even if the iPhone’s battery doesn’t last 3 days, charging it once a day is not a problem.

7. The iPhone Has No Native Video Recording Capabilities

And neither does my BlackBerry! I have an 8820, no camera at all. I mean WTF?! I have to step down to the Curve which is a rickety P.O.S. to get a camera? No way.

6. The iPhone Is Too Darn Expensive

Considering I didn’t pay for my BlackBerry (my company did), this doesn’t apply to me again. Plus the difference between an 8820 and an iPhone is worth the benefits.

5. The iPhone Doesn’t Support VoWi-Fi–Even Though It Could and Should

And neither does my AT&T BlackBerry! Not that I really care though since I am on my company plan with huge voice and data discounts.

4. iPhone User? No GPS for You

Ok, this point isn’t completely negligible. I did run TeleNav on my BB for a while. It is incredibly cool, and does some very awesome things with GPS. But in truth I never really used it. GPS for Google Maps was plenty for my usage.

I’d miss the GPS in Google Maps on an iPhone but not seriously enough to not buy one.

3. Want an iPhone? Hope You’re Ready to Switch Wireless Carriers…

Wrong again! I’m already on AT&T. I’m already suffering with Edge (no 3G on AT&T BlackBerrys).

2. No Physical Keyboard? No Thanks.

I am pretty good with the BB keyboard. I will concede that using a virtual keyboard will suck for quite a while. But I will get over it. I am flexible and adjust quickly. The increased screen size is worth the short period of adjustment.

1. The iPhone Third-Party Apps Debacle

The only apps I would miss, that either don’t already exist, or don’t have a webapp replacement, is my Google Talk or an IRC client. There are ways around both via Webapps, though not quite so pretty. Oh well. not a big deal.

In summary, BlackBerry has GPS, better 3rd party app support (for now), and a physical keyboard. iPhone has a *camera*, huge screen, total hawtness, awesome mobile web browser, media player that doesn’t totally suck. I can certainly say I’m going to get an iPhone as soon as I can.

Due to the comments I recrived on the last post on this topic, I decided to make a few changes.

First I want to say thank you to everyone that showed interest. Apparently this type of plugin is desperately needed. My initial version was just a quick hack to transfer meta data to and from my iPod. Note the extremely hackish nature of the link between iPod and rhythmbox tracks (filename only).

Now for the changes:

1. The most common complaint was the rhythmbox crashing bug (Segmentation Fault). This is caused by the gpod module when it attempts to locate and read the itunes database on the iPod. My fix was to just check if gpod found the itunes directory, print an error to the console, and skip any processing at all. This will prevent killing rhythmbox, but doesn’t actually fix anything.
2. More intelligent rating updates. I used mockenh’s idea to compare last played dates to determine which rating to use in case of a conflict.

I don’t really have the desire to implement playlist, or podcast synchronization since I have very little time, and I am only a mediocre programmer at best. If someone wants to swipe my code to build on, they are more than welcome to.

Some notes about my implementation.

1. I just use a periodic rsync to copy music from my iPod to my PC. rsync -av /media/BFUNGUS/iPod_Control/Music/ ~/Music/ Change any paths as necessary.
2. Since I don’t copy songs to the iPod using Linux, I didn’t write that support into it
3. The detection of the iPod mount location is dependant upon the GnomeVFS module. It must correctly recognize your iPod as a Music Player
4. The python gpod module must be installed. Debian users can apt-get install python-gpod

ipodsync v0.2

• Standing in line for My Chemical Romance #
• Opening band kind of sucked. Still waiting for MCR #
• Dude. MCR puts on an awesome show. #

Powered by Twitter Tools.