Having mainly used CVS my entire professional life (all of eight years), I've grown accustomed to its eccentricities especially when it comes to branching (and merging) and file management. Once I saw Linus's Google TechTalk on Git¹², I decided that I'd give Git a try. I like it so much more than CVS that I'm plugging it wherever I can. Admittedly, this is probably not so much due to Git being awesome (which itself is somewhat similar to Mercurial, Bazaar, or Darcs) but rather to CVS being horrible.

I found Git a bit confusing beyond the update code and commit work flow. Everything being a SHA1 sum led to much of that confusion. A commit is a SHA1 sum. The tree is a SHA1 sum. Content is a SHA1 sum. Reading a few articles and blog posts of other folks who were at one time or another similarly afloat in a sea of "Dur?" was tremendously helpful, especially Git from the Bottom Up by John Wiegley. Git's documentation is also helpful but not so much the man files than the online documentation including the CVS migration manual and Git User's Manual.

After reading Git from the Bottom Up, everything pretty much just clicked. The structures in which Git stores content is really easy to digest and is the basis for the type of work flows that can be achieved that you would never imagine or find possible to do in CVS.³ Git at one time or another was called "the stupid content tracker," and it really is just that (as an aside, you may find this discussion between Linus and Bram Cohen about merging strategies interesting)⁴. The rather basic content tracking is what allows for its distributed nature and painless branching and merging.

Think of all the things that one must do to set up centralized revision control. First, you have to find some place for the repository to live. Then, you must give access to commit to the repository to those who need it which may entail giving them login access to the machine on which the repository lives. After everyone is able to talk with the repository, rules about branching, merging, and tagging are usually set up to avoid problems.

With Git, the repository lives on the developer's machine. When he or she gets to the point of wanting to share that code with a wider audience, it is simply a matter of making it available via HTTP which they're likely to have set up before hand. (See http://git.kernel.org/ for an example of gitweb, a nice front end to the directory structure that a repository lives in.) Any changes that someone else would make are sent by e-mail, done over HTTP as the clone was, or could potentially occur over SSH. (They'll rely on SHA1 sums of the content, tree, and commit history common to both repositories to facilitate the merge.) This eliminates a lot of the annoying server administrivia to manage a repository.

Furthermore, setting up rules for branching and merging are completely unnecessary because the repository you cloned from the original programmer is yours to do with as you please. You can commit without regard to whether or not it will break the code base or someone may be checking out code later on in the day. Things like git rebase --interactive are sufficiently advanced to be freakin' magic to CVS users such as myself and help in creating a single commit or series of commits to send back to the original (and possibly authoritative) developer for inclusion in their repository.

This has been rather haphazardly put together, but I hope that you'll take a look at Git if you haven't already. I highly recommend reading Git from the Bottom Up because it is interesting from a computer science standpoint and serves as a primer to the staging area and content storage model Git uses. I'm hoping that as time goes on, I will have worn down my co-workers' resolve (really, we just have to find the time to do it) and we'll finally port our CVS repository to Git. In the mean time, I'll be happily coding away on my personal projects with Git.

This post was originally posted on Log Burning, a personal blog I had on the University of Minnesota's now defunct UThink platform. Its content and formatting have been edited.

Although I wouldn't call myself a Mac zealot, I watched the live keynote updates on macrumorslive.com just like everyone else. Most of what was revealed was expected. There were three pieces I was most interested in: an addition to the SDK that was an attempt at pleasing those who wanted background processes, a way of adding applications to the iPhone without having to use the App Store or have an enterprise SDK license, and the addition of a GPS chip.

The push notification service, as they call it, is pretty neat. It does take care of a good 75% of use cases for background processes on a mobile device--but not all. Say you wanted to create a service that sent severe weather updates to a user's phone based on their location. If you assume the user is stationary, the push notification service will work.

However, if they're mobile, they could be driving 70 MPH into a dangerous situation and there's nothing you can do to warn them (although the large line of dark clouds will probably tip them off). Apple missed the boat in not doing an information pull at the same time as they do the information push. There's not a whole lot of other data that would change over time while the user is not utilizing their phone--and I'm sure there are other uses for live user location data. Maybe they'll work on that after September.

The ability to add your own applications to the iPhone (and 99 of your closest friends) without having to go through the App Store or shell out for the enterprise license is awesome. I figured that they would at least allow personal applications to be put on the iPhone, but the ability to send them to friends, family, co-workers, or whatever is great news. I guess others expected this, but I found it to be a nice surprise.

Then there's the addition of a true GPS receiver. Being an amateur radio operator (K0WMS), it was at this point that an idea slapped me in the face so hard that I have to try and get to work. Now that the iPhone has a GPS, you can write custom software for it, and there will be an easier to use headphone jack--it seems that it would make for the perfect APRS unit. Just connect the iPhone's headphone jack to the packet radio adapter on your trusty VX-7R using the sound card to generate both the data stream and PTT signal and you're set.

As strange as it sounds, this might be the killer feature that will push me over the edge (no pun intended) to upgrade, rather than the better internet data speeds afforded by 3G. I will say that I have found EDGE to be an annoyingly slow service. If AT&T is reasonable about upgrading to the iPhone 3G, I may have to consider it. I hate you, Steve Jobs.

This post was originally posted on Log Burning, a personal blog I had on the University of Minnesota's now defunct UThink platform. Its content and formatting have been edited.

Initial Thoughts

In terms of the specifications and looks of the laptop, the SZ791 is really nice. I like the way that it looks, and it weighs at least two or three pounds less than my old Toshiba laptop. I was waiting rather impatiently for NewEgg to stock this laptop, which left enough time for the MacBook Air to be announced. While the SZ791 isn't as thin (at most 1.5" thick), at four pounds it's still rather portable (and certainly more user-serviceable).

For those that cannot be bothered to look up the specifications of the laptop:

• CPU: Intel Core 2 Duo T9300 (Penryn, 45nm) 2.5GHz, 6MB shared L2 cache
• RAM: 4GB (DDR2 667)
• Video Cards: nVidia GeForce 8400M GS, Intel GMA X3100, 1280x800 native resolution (13.3" monitor)
• Hard Drive: SATA, 250GB, 5400RPM
• Networking: Modem, gigabit LAN, 802.11 a/b/g/n, EV-DO (CDMA, Sprint), Bluetooth
• Operating System: Windows Vista Business (32-bit) pre-installed
• Etc.: Webcam, fingerprint reader, Firewire, card reader, DVD burner

Those of you paying attention to the specifications will notice a glaring problem with the initial configuration of this laptop. It comes with a 32-bit operating system pre-installed, but contains 4GB of RAM. Without going into detail, this essentially means the 32-bit OS will not give full access of the 4GB of RAM to programs. To do that, you'll need to use a 64-bit operating system (such as any Linux distribution these days or by purchasing a 64-bit version of XP/Vista). With the default installation, Vista reported a little over 3GB of RAM.

I had access to a free copy of 64-bit Vista Business and was planning on dual-booting the laptop anyway so reinstalling Windows was already on my list of things to do (better to nuke the bloatware from orbit, it's the only way to be sure). I can't really blame Sony for not wanting to ship a 64-bit operating system with new laptops, but I naively thought that this would not really be a problem. Sadly, I was wrong. Sony does not supply 64-bit drivers for this laptop. Other, older Vaio laptops have unofficial 64-bit drivers, so with a bit of luck Sony may supply them for the SZ791.

What Works, What Doesn't

Let's start with Vista. You will not find a Vista recovery CD with your SZ791. Instead, you will find a CD (DVD? I didn't open it.) that will allow you to downgrade to Windows XP. If you want recovery DVDs for Vista, you'll have to make your own. Sony has put drivers, recovery software, and apparently a somewhat clean Vista install on a separate partition on the hard drive which can be copied to two DVD-Rs (using the built-in burner, of course). Those DVDs are important because they will contain most of the drivers which can also be used on 64-bit Vista.

There are a few rather important drivers that will refuse to install which include both video drivers (both the X3100 and the nVidia 8400M GS), the Sony function keys (the programmable buttons and the LCD brightness) and touchpad. The most infuriating of these is the trackpad (no scrolling using the right and bottom parts of the trackpad--it otherwise operates just fine) and the function keys because who knows when Sony will decide to release 64-bit versions. Other drivers, including the X3100 drivers are available from Windows Update, "Problem Reports and Solutions," or manufacturers' web sites.

I won't go through the full list of what works and what doesn't because I don't have an exhaustive list handy. The main features mostly work and a good percentage of the extras work. I haven't tried the webcam (I would assume, though, that it will fall in the same category as the trackpad and function keys), the CDMA modem, the card reader, or anything in the PC Express slot.

Linux is, of course, a much brighter picture. I installed Fedora 8 on the laptop and pretty much everything works out of the box. I have not yet attempted to install the drivers for either video card, but the X3100 deals with Compiz just fine (if you ignore the blacklisting). The wireless network connection also works just fine, however, the wired ethernet driver appears to be misconfigured. I haven't been able to track down the problem (what little attention I've given it so far). Otherwise, audio drivers, all features of the trackpad, controlling the monitor brightness (via the command line) all work without a problem.

Bottom Line

I love this laptop. I love the fact that it dual-boots without a problem. I don't like that Sony has completely shut out anyone that needs or wants to use a 64-bit version of Windows on their laptops, but I suppose that's their prerogative. I'm sure that with time they'll start pushing out more beta drivers and perhaps even support 64-bit Vista on it some day. In the mean time, it works without any major issues with 64-bit operating systems if you can rough it on your own. If 32-bit Vista works for you, then there's really no reason to be afraid of picking this laptop up.

I only have minor nitpicky issues with the keyboard (the size is great, but the key movement is somewhat slushy), the cover over the modem and ethernet ports (connected via a dongle attached to the side of the body), the antenna (another flimsy-feeling plastic piece that seems like it could be accidentally ripped off rather easily), and finally the battery (it's not solidly connected to the body of the laptop, it moves around slightly in the battery bay when you set it down). They're not deal-breaking problems by any stretch of the imagination but they are in the way of what would otherwise be a solid—literally and figuratively—laptop.

Over the last seven years, Ancient Imports has grown beyond both of our expectations. He was able to quit his job at the postal service and work on the site full-time. We've outgrown two hosting providers, the most recent event happening a few weeks ago.

We moved from a poor shared hosting environment to a spiffy virtual private server. It's the closest thing to having full control over a physical machine as we can get right now. It's fun for me because I essentially have full control over the virtual machine, which means I'm pretty much free to do whatever I need to do to implement new functionality. The cost, however, was that I also have to maintain the security, e-mail services, and DNS that were previously dealt with by the hosting provider. The classic blessing and curse.

We were under a somewhat tight deadline to switch over (long story short, they blamed us for the problems we had with their service--that did not sit well with either of us), so I just threw up the e-mail server and configured it to make sure the mail was still delivered. That meant no spam protection. After about two weeks, the deluge of spam started to bother me enough to do something about it.

I was pleasantly surprised at how effective just a few anti-spam measures were. The first counter-measure I added was to make the server a bit more strict as to what it will accept as a properly formatted message (e-mail originating from domains that actually exist, etc.) which I assume is not immediately recommended because of the extra DNS lookups it incurs. The second was to check a DNSBL to see if the originating IP address is a known spammer (also another DNS lookup). Both of these tweaks killed a bunch of spam with the small effort of adding four lines of code to the configuration file.

The second, more involved, counter-measure I added was greylisting. This is a really nifty technique that is mostly invisible to people sending or receiving mail. The e-mail server will feign unavailability to any sender and recipient pair that it hasn't seen before. Upon receiving the temporary error message, normal e-mail servers will attempt to redeliver the message in another 10-20 minutes, at which point the server will remember the previous attempt and accept the e-mail.

Most software used by spammers to send their advertisements, however, are not so well behaved. They're more interested in sending out as much mail as possible in the shortest amount of time. This means that the spammer is unlikely to attempt a redelivery (at least using the same source e-mail address) to the same person in a reasonable amount of time. Even if they do, they greatly increase their chances of appearing in the DNSBL the next time they attempt to connect. Greylisting essentially gives you a two-for-one special.

As for numbers, the server's been running with the new counter-measures since early Sunday morning. Since then, 611 attempts were blocked by the SpamHaus DNSBL, 163 attempts were greylisted, and only 40 e-mails were actually delivered to Marc and myself (and most of those originated from the website itself and not from outside sources). Of course, the default behavior of rejecting e-mail for unknown users (and domains) is the most effective "counter-measure." In the same period, the mail server rejected 3,957 attempts at sending mail to ghosts.

This post was originally posted on Log Burning, a personal blog I had on the University of Minnesota's now defunct UThink platform. Its content and formatting have been edited.