Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 378

Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead in /usr/local/www/grapefish.org/blog/files/rapidBlogHelpers.php on line 365

• 2010: an email odyssey

2010/03/18 06:49 | articles
where I've been

I wanted to claim that the reason I haven't posted in so long was that I was working on this post, but that just wouldn't be true. I don't really have a reason, except maybe that we had a baby. Since that one doesn't require much in the way of justification, we'll just go with it.

I may or may not have posted in the past about trying to find a good email client. Well, truthfully, the perfect email client. There may not be such a beast, and frankly I don't believe that there is yet, but I'm willing to look for it. I've done a bit of evaluation of different mail clients in the past, but this one is going to be as comprehensive as I can manage.

what this is all about

Ever since I switched to OS X on my main workstation I'd been using Apple's built-in Mail client, which is not bad. I grew fed up with it at some point, though, and it was due to it not being able to read mail consistently from the several servers I asked it to do so from. The most problematic? Apple's own MobileMe server. There were a couple other issues that I don't recall offhand, so I'll be re-evaluating Mail as part of this larger project.

First, the ground rules: I'm looking at desktop mail clients for OS X. I don't have a need for my email to be cross-platform, as when I don't have access to my main computer and I want to check my mail, I've found my iPhone to be sufficient. Interestingly, it's the iPhone's mail client that I ultimately end up judging all others against. It's simple, fast, and it works. It meets most of my other criteria, too. But more on that in a minute.

why not gmail?

It's a fair question. The biggest reason I don't use gmail for my primary mail client is pretty simple - I'd have to turn over my mail handling to them, and I run my own mail server the way I want to run it. I don't like how they handle spam, I don't like adds in my mail interface, and I don't know exactly what they do with any information they might collect.

I have a decent web interface to email on my own server, which is nice in the pinch times I don't have access to my desktop app and my iPhone doesn't work for whatever reason. It's not good enough for every day, but then neither is gmail, as far as I'm concerned.

the process

I'll be spending a week with each of the clients I've selected as my exclusive email client, or until I can't stand it anymore, whichever comes first. If that latter bit sounds like a cop-out, well I guess it is, but there are certain fatal flaws that I just can't ignore for a minute, never mind a week. Case in point: GNUMail was going to be in the running, but when I first fiddled with it I found that it couldn't authenticate to my SMTP server, which made it impossible to send mail. Sending mail is not only a critical feature, it's one I never even thought about listing as a critical feature, since it's so basic to the idea of what an email client is. I've since learned that I can probably make it work by adding a setting to the MTA on my server, which handles SMTP: broken_sasl_auth_clients. Anyone who knows me at least a little will know how likely it is I'll turn that on. Not considering GNUMail doesn't exactly leave me starved for choice, though.

the contenders

Apple Mail
Eudora
GyazMail
Mailsmith
Mozilla Seamonkey
Mozilla Thunderbird
Mulberry
Opera Mail
Outspring Mail
Postbox
PowerMail
Zimbra Desktop

Of these, Apple Mail and Outspring Mail are my former and current clients. The deciding factor with Outspring when I chose it last year was that it supported data detectors, like Apple Mail, which I find handy. It's not a requirement, though, since I don't use them often enough to really make a difference.

I also currently use Microsoft Entourage, which is the mail client in the Mac version of their Office suite, but I only use it for work email. Both it and Apple Mail will work with an Exchange server, but since they've released the Web Services Edition of Entourage, it works well and I've found no reason to stop using it. I don't use it for my personal email since I like having a separate client for that. There's a separation of duty, and for whatever reason, a separation of requirements somewhere in my brain that keeps Entourage in it's own space.

Lastly, I will mention that I'm greatly looking forward to the release of Letters, which is a new, open source collaborative effort that comes from some of the best minds in the Mac community. John Gruber of Daring Fireball is heading up the project for his stint as President of the project; his job is to ship version 1.0. I can't wait to try it.

status so far

Since GNUMail didn't even make it out of the gate, I've got GyazMail currently serving as my mail client. I'm not sure exactly in which order I'll try them, except that Outspring and Apple Mail will be last. You might also wonder why, if I've been using Outspring for a year, I'm looking to switch. Well, that's a longer story, but it has to do with the upgrades to my mail server that I've made recently, and Outspring's inability to filter based on custom headers. This wasn't a big issue before, but it is now, since it no longer behaves the way I want. But that's getting into territory I'll reserve for later, when I review that client.

Until then, stay tuned!
comments

• "tco"

2009/06/15 09:49 | articles
There's a lot of talk on the web these days about the new iPhone, and the prices, and what people are calling "TCO" or total cost of ownership.

The people whining about the upgrade pricing from AT&T are usually those folks who bought a new 3G phone last year, and now are surprised to find that AT&T are going to hold them to the contract they signed and charge them for an early upgrade. You know that $199 you paid last June for the iPhone 3G? Well, that's the contract price, and the contract is 2 years. If you want to upgrade early, you pay more for the new equipment. This would be true of any phone bought from AT&T before upgrade eligibility, but all the spin is that it's some mass scheme to rake iPhone users over the coals. That makes me go "Hmm."

However, there is something to whine about here, and it's not the cost of the phone - it's the cost of the plan. And this is partly preface to the TCO whiners, except that it's a legitimate complaint I haven't seen anyone make.

The whole idea behind the contracts the carriers make you sign is that it allows them to charge you less for the hardware upfront. They call this "subsidizing", but what I'd like to know is this: if I get a deal on the hardware for a contract, why can't I pay less per month if I buy the phone outright? I think this is where the real cause for concern is. You don't get a discount if you don't choose a subsidized phone. So you might as well take advantage, even if this means you can only upgrade once in two years.

Well, the truth actually is, you can upgrade as often as you like, but you'll pay full price for the hardware. Which brings us back to the subsidy question, and why you can't have a less expensive monthly plan if you're not paying your carrier back for the low cost phone.

Lastly, our folks who talk about the total cost of ownership. They'll tell you that your new 16GB iPhone 3Gs doesn't cost $199 - oh, no. It costs you a whopping $1,855. Where do they get that from? Well, they add up the cost of the phone itself ($199), the cost of the cheapest monthly service plan available at AT&T ($39 per month for two years = $936), and the required data plan for the 3G and 3Gs iPhones ($30 per month for two years = $720); multiply the service plans by the 24 months in the contract, and your new phone costs you $1,855.

That's a lot to pay, isn't it? Especially when compared to the multitude of phones you can get for free, even from AT&T. But wait - if we're including the monthly service in that iPhone's price, don't we have to include it in the free phone's price, as well? You're not getting that free phone without signing a two year contract, either. So let's add that back in, at $39 per month: your free phone is now costing you $936. While still less than your iPhone, that does change the picture some.

Now, if we compare the iPhone to a more reasonable competitor, like the Blackberry, we'll have to add in that mandatory data plan charge as well. That brings our total to $1,656. The subsidized price of the least expensive Blackberry is $99, for a total of $1,755, which is of course only $100 less than your iPhone costs. Opt for the less expensive $99 iPhone 3G if you don't need the new features, and your price difference evaporates completely.

The point here is that any phone with a 2 year contract is going to cost you some money - almost a thousand dollars, in fact. That's not free by any stretch of the imagination. It's also a good way to see why you should compare carriers and phones, if you're not interested in a specific phone or manufacturer, it's possible you can get the same hardware from T-Mobile or Verizon or Sprint. And then comparing your total cost over the length of the contract is good advice; you could save a significant amount if the fees are lower and the service levels are comparable.

So shop around, but do make sure any comparison is like for like, and includes all the applicable charges on both sides.
comments

• standing up

2009/05/12 06:06 | articles
Sometimes the right thing to do is the hard thing to do. For a person, this can mean having to give up something that is desirable to be on the right side of your conscience. For a company, this can mean taking a stand on an issue, even when not doing so is permitted, and even protected, by the highest law of the land.

Here are two reasons I am no longer on Facebook, and why I will not return.

Facebook needs to do what is right, not hide behind what is allowed.
comments

• fallacy of choice

2009/04/12 07:56 | articles
A common criticism of Apple's hardware selection is that they do not offer enough choice. This extends to their being no low-cost, highly expandable desktop solution (true or not), or the often-heard mantra that Macs are just "too expensive".

Something I've been encountering more frequently in other product lines, however, has led me to appreciate Apple's short list of products, which (mostly) have clear lines of distinction between them. The latest example I've found of this is MSI's Wind product page.

It lists 14 separate versions of their Wind netbook, 10 of which cost $429.00, and 4 priced at $479.00. (I originally thought there were only 5 models presented, until I noticed there were 2 more pages!) At first glance, it seems impossible to know what the differences might be. All of the product descriptions on the first page are identical. The next pages reveal some differences, but I'll be damned if I can remember what any of them are. It's the first instance of any "real" specs, though - the last entry on page 2 includes the processor speed and amount of RAM.

How can anyone begin to make a decision based on such a dizzying array of poorly-named, nearly identical products? You could easily attribute this to poor web design, but there does seem to be a huge amount of poor design going around, if that's the case. We find the same kind of selection at Dell's Laptop Page, where 13 different category links lead to between 2 and 4 models each, for a total of between 26 and 52 possible selections.

It's no better at Acer (33 notebook models in 4 categories, plus 2 netbooks), HP (17 different series in 4 categories, with an indefinable number of models per series), or Gateway (7 notebook series with between 1 and 7 models each).

Lenovo, I think, takes the prize. They feature 3 meta-categories of notebooks, each sporting 3, 6, and 2 series of notebooks, each of which contains between 2 and 6 different models. And all of these models, at most of these vendors, is customizable.

In Lenovo's favor particularly, however, their website does do a reasonable job of describing and contrasting the different product lines. A prospective buyer can at least drill down into the type of product he or she is looking for. At MSI's website, I don't even know where to begin.

Adding to all of this, then, is the potential option of more than one version of Windows Vista, once you've finally figured out what hardware you'd like, balancing all the relevant feature combinations. It's no wonder buying a PC is something friends and family frequently enlist help for, from the more knowledgeable people they may know. I'm not sure what I'd do, though, if asked. I can't even handle beginning such a search for myself, in such a sea of impenetrable model numbers, line and series designations, or spiffy color combinations.

It all makes Apple's Macbook Pro seem like a... well, easy choice to make.
comments (2)

• thinking it through

2008/10/05 10:11 | articles
Recently PETA sent a letter to premium ice cream maker Ben & Jerry's, suggesting they make all their ice cream from human milk rather than cow's milk. Surely it's a tactic meant as a thought-provoker, a suggestion full of shock value to get people thinking about where their ice cream comes from. Because they can't honestly be suggesting that be the path we take. Can they?

Imagining that their goal is to have all ice cream production utilize human milk sources rather than bovine isn't too hard, but if you run the numbers it becomes obvious they haven't thought this through at all.

The US alone consumes two billion gallons of milk as ice cream every year. That's a little under five and a half million gallons a day. Assuming a lactating human female can express a gallon a day—which is probably a lot for an 8-hour shift—you'd need a workforce of around six million women or more, to allow for vacation days, sick time, etc. Could you get that many women to choose such a career path? Keep in mind that since diet affects the taste of milk dramatically, they would have to be on strict diets while working, unless flavored ice cream from flavored milk became popular. Even then, they'd have to eat specific foods.

If we assume we can find six million women willing to produce milk for ice cream, we'd have to hire them, of course, which means salary and benefits. I would think an absolute rock-bottom number would be around $35,000 a year, and very likely quite a bit more. This makes our single gallon of human milk cost a bare minimum of $100. I'm not sure how much Ben & Jerry's pays for their milk, but I would lay long odds it's less than a hundred bucks a gallon. In fact, since I can buy a gallon of whole milk at the market for about $6.00, I'd guess that bulk buyers can probably get it for less than that, maybe $5.00 per gallon if they're getting really high-quality stuff, or organic, or non-GMBH, what have you.

Still with me? We're almost there! It takes about a gallon and a half of milk to make a gallon of ice cream, and since we're working with minimums so far, we'll stick with it and just assume Ben & Jerry's doesn't use more to create their premium ice creams, which have less air (and therefore, more of everything else, including milk) in every gallon. Now we know that their pints of ice cream, therefore, cost them $0.31 in milk to produce.

But human milk will cost them $6.25 for that same pint, or twenty times more than cow's milk. If a pint of Ben & Jerry's is $5.00 retail, and we generously assume that only 25% of the cost to produce it is in the actual ingredients, and furthermore that 80% of the ingredient cost is in the milk and milk products, it's not too far to walk to set the price of human-sourced premium ice cream at $30.00 or more.

Once you get over the creepy factor, and get past the FDA, and the ACLU, and whoever else might have a problem with this little scheme, you're still going to have to fork over a whopping thirty bucks at retail for your new human-milk pint of Ben & Jerry's latest limited edition: "Don't Be Such A Baby".
comments

• what's all this then?

2008/08/04 19:15 | articles
I'm pretty sure Chevrolet doesn't have a monopoly because they're they only carmaker that sells Impalas. So why are Psystar claiming that Apple have a monopoly on OS X?

Nobody ever sued IBM for selling AIX only for high-end PowerPC machines, or OS/400 only for AS400 hardware, or z/OS only for their mainframes. Likewise with Sun and Solaris (though Sun did eventually release a version that you could legally install on any PC). So why does everyone expect that Apple should sell OS X separate from its hardware, to the degree that they're willing to base buisiness models on violating Apple's software license to sell their own machines with the Mac OS?

And then, when Apple file suit to get them to stop, they start whining about monopolies. I just don't get it.
comments

• how to improve community software development

2008/08/03 12:39 | articles
Lately I've been wrestling with various issues in Firefox, the successful web browser which is licensed under the GNU Public License, or GPL. Because of the terms of the license—in theory—anyone can contribute changes to the code base, which in turn could change the way the end product, Firefox, looks or operates. I say in theory, because many times that's just not how it ends up working.

Certainly the core developers who control access to the source code on which Firefox is built can't accept changes without review; the number of contributing developers could quickly reduce the project into non-functional chaos. However, there are good examples in Firefox's history of code that really ought to be merged, and isn't.

Yes, this is reflective of my opinion on such changes, which is actually the whole point. Often times, changes regarding the behavior of the tab bar, the operation of web fonts, or the default function of the URL bar end up being back-and-forth struggles of opinion or rhetoric that can span years. They often involve the core developers, among whom nobody is more right than anyone else. The upshot of these gridlock discussions is often that the particular feature under debate goes unimplemented, or gets implemented badly.

Looking at the bug tracking system and the subsequent comments by posting developers often makes me simply shake my head. Language and opinion directed at peers in the community that would get one reprimanded or even dismissed in any other environment isn't that hard to find. And I think that hits upon the problem.

No proprietary software department would allow such debates to stretch on for weeks, much less months or years. At some point, preferably as early as possible, the director of the project would be required to step in and simply make a decision. If one of the more passionately opposed developers were to balk at this, she might be reassigned to another project, quit her position, or even be fired.

In the community development world, that kind of exertion of control really doesn't exist. Projects get bogged down around a single person's idea of what is "right and proper", and when that person is the one that controls access to the source, there's no recourse.

The way to improve the community software development model is to find a way to fire people.
comments

• no charge

2008/07/17 10:13 | articles
The latest iPhone 3G is causing a bit of a stir with accessory owners, who are finding that in some cases their 3rd party gear won't charge their new phone. Apparently this is due to Apple's removing the Firewire charging pins from the iPhone 3G's dock connector, so it isn't something that can be fixed via a software change.

Accesories for the iPod and iPhone can supply power for charging in one of two ways - via the USB connectors, which are a 5V source, or via the Firewire connectors, which are 12V. Hit particularly hard by the change to the iPhone 3G will be owners of wired car kits, which are nearly all 12V, so they could avoid stepping down the voltage.

Last night, Jer and I confirmed that his 3G will not, in fact, charge in my Dension IceLINK car cradle, which puts a bit of a dent in my plans to upgrade to the 3G.

Especially given the harder use the battery seems to get with the new version of the iPhone, not being able to charge it while mobile is a significant drawback for me. We'll have to wait and see what, if any, response Apple has to the issue, but I suspect that upgrading my phone will involve upgrading my car kit, as well.
comments

• universally speaking

2008/07/13 08:13 | articles
Universal remotes are—depending on your perspective—either a luxury or a necessity for those of us with more than one electronic device to control, even for a task as simple as watching television. Watching some of my comrades wrestle with the settings on their HD panels hasn't made the grapefish home accelerate our plans to upgrade the standard-definition tube in the family room, but I know when we do eventually take the unavoidable plunge we'll need something like the Logitech Harmony more than ever.

Lukas Mathis over at ignore the code has recently reviewed the Logitech Harmony 1000 and its sometimes lacking UI and programming software, and I have to say that on most of his points I can't disagree. He sums up one of my biggest gripes with the programming software perfectly:
Never put anything into the user’s home directory or Documents directory! There’s a place for application data and preferences, and it’s not in the user’s home folder.
Logitech isn't known for having the best installers or making the right choices when it comes to putting software on a Mac, having recently caused a rather nasty issue for people upgrading to Leopard because of their choice to include the "APE" code-injection framework from Unsanity. As John Gruber puts it in the aforelinked article:
Unsanity’s response more or less boils down to, APE users should check for updates and upgrade to the latest version. That’s fine advice for any user who has knowingly installed APE, but the biggest problem seems to be that many of these blue screen sufferers had no idea APE was installed on their systems.

How could that be? The most common route is Logitech Control Center, the mouse “driver” software from Logitech. “Driver” in quotes because it’s utterly absurd and completely irresponsible for Logitech to base their mouse software on a completely and utterly unsupported-by-Apple system software modification.
I have used Logitech mice and keyboards on my Macs in the past, but lately haven't because of the APE framework being a part of their software installation, posing an unnecessary risk to the stability of my machine. Since their Control Center is usually required to get the additional functionality of their hardware, if you choose not to install Input Managers like APE, you're stuck without the benefit of all those extra buttons.

The Harmony Remote Software doesn't install anything quite so invasive, but Lukas' other issues are dead on - the nagging Remote Assistant, which, like him, I can't seem to banish from our Harmony 720 no matter what I do (and I've followed the procedure many more times than once, which is all it should take); the rather obtuse and oddly limited troubleshooting section of the configuration software, which still has me furrowing my brow over the power settings on our DVD player, much like Lukas' issues with his projector. I also can't quite get the power settings correct for our new slimline PlayStation 2, which turns on when I switch to the Game activity, but doesn't respond to anything the remote is programmed to send when I try to turn it off.

I'm not completely turned off by Logitech's universal remotes (no pun intended); the models we've had work well most of the time and do save space on the coffee table and cut down on the amount of batteries we go through—the 720, like most of the recent models including the 1000, is rechargeable. I'd still recommend the product to anyone interested in a universal remote, but today there are other choices in the market.

The Philips Prestigo 8015 offers 15 device control, macros, and converts the color display into a quick-access channel selector with full-color network icons for rapid selection. It uses a self-programming model to identify devices, and so doesn't require a PC to set up.

Sony's latest edition of the Remote Commander is the cumbersomely named RM-AX4000A, which is more of a tabletop remote than the usual handheld design. We owned the original Remote Commander, and while it was a capable unit, it did lack some of the features that the more recent models have, such as macros and activity-setup buttons. The 4000 seems to have added those capabilities, but still missing are two of the biggest reasons we replaced it: there are no hardware transport keys, and no hardware number pad. The transport keys are especially useful while watching movies in a darkened room, and having to activate the backlight and look at the tiny text or symbols on the touchscreen was annoying. We much preferred the ability to pause and rewind etc. by feel.

You can also find Harmony-based remotes from several manufacturers, including models from Monster Cable and Harmon/Kardon. The Monster model, while horrifically priced, does offer some features the Harmony line lacks, such as the ability to control hidden devices via an included RF-to-IR bridge.

If it comes time to replace our 720, we'll most likely be looking at the Philips. It does just about everything I'd ask the Harmony to do, and is available for significantly less money.
comments

• on wikibout

2008/06/18 07:21 | articles
Walkabout, if you believe the tales, is an Australian Aboriginal ritual, wherein at a certain age they would go wandering off into the wilderness as part of a rite of passage. The concept was made popular in the U.S. by the Crocodile Dundee films, and it's certainly a staple of Australian popular culture.

xkcd has a strip on The Problem with Wikipedia, which illustrates that this same wanderlust can consume one while browsing the internet, as well.

I call this phenomenon wikibout - though I doubt I'm the first or only one to do so. I remember the promise of Hypertext back when the web was young, which was when people still knew who Tim Berners-Lee was and used the term WorldWideWeb a lot (that's where the www. in most URLs comes from).

It does seem like only in the last couple of years, though, that the web has become truly interconnected; there is a way to find almost anything starting almost anywhere, as long as you're inclined to keep reading long enough. Though going on wikibout at the wrong time can get in the way of actual work or actual play sometimes, it's also a great way to find yourself learning something you never thought you'd need to know. And, most probably, don't need to know.

You'll notice many of the terms in this post are underlined, but they're not links. That's on purpose. Pop them into your favorite search engine and try a few of the hits further down the page. Then, click a few links from there. You never know where you might end up.
comments

• even when they get it, they don't get it

2008/02/16 04:37 | articles
eeTimes has the story of how the Users' love affair with iPhone stumps Mobile World panel.

Reading this, I remember all the commentary around Palm CEO Ed Colligan's remarks in early November of last year regarding Apple and the iPhone:

Responding to questions from New York Times correspondent John Markoff at a Churchill Club breakfast gathering Thursday morning, Colligan laughed off the idea that any company — including the wildly popular Apple Computer — could easily win customers in the finicky smart-phone sector. “We’ve learned and struggled for a few years here figuring out how to make a decent phone,” he said. “PC guys are not going to just figure this out. They’re not going to just walk in.”


Turns out that's exactly what they did, and the Mobile World panel quotes show that the industry still can't figure out why.

Seriously, "identifying need states"? "Touch and pre-touch input"? They're stumbling around in the dark, and even when given a touchstone in the iPhone, a real, in-the-wild product to duplicate, they'll get it wrong when they try. If their history to date is any indication, they'll produce bulkier, uglier versions of the iPhone that just simply don't feel good in your hand. (The iPhone does). They'll cram it with more features and wonder why that doesn't get them sales. They'll put in touch-screens and swooshing graphic feedback that somehow misses the point of what a swooshing graphic feedback should be telling the user - which always needs to be something useful. They'll miss the point entirely.

The first commenter on the above linked story has it exactly correct; Apple are succeeding by repositioning the competition, making a device/software/service stack that nobody else currently in the industry can control top-to-bottom; a unified experience. That's a tough nut to crack for the cell phone industry, but the very first step is to make a phone that has a user interface that doesn't suck. That seems like an obvious goal, and I'm quite certain nobody at Nokia or Ericsson or anywhere else isn't trying hard to do it, but they're missing the magic part, the part that Apple provides, which is the part where Ed got it flat fucking wrong.

Apple were going to just "walk in", because they're "PC guys", or said another way, not cell phone guys. These are the same engineers and designers who came up with the iPod, you may recall, which when it was released was more expensive than the competition, did less, and in many cases, held less music. And it still swept the industry. They followed it with the iPod mini, which was roundly criticized at its release as being far too expensive, and went on to become the best-selling iPod to date. They did the same thing with the original iMac, and as John Gruber explains, they're doing the same thing with the MacBook Air right this second. By the way - the Air is a product for a market that doesn't yet exist, but it's a market that Apple is both betting will exist and at the same time, is helping to create.

Apple knows something the cell industry (and the music player industry, and the computer industry) doesn't - they know what their customers want. All the rest of the world has to do to catch up is the same thing: give it to them.
comments

• spore is coming

2008/02/13 03:22 | articles
Will Wright is the creator of the popular SimCity and Sims series of games, and his new Maxis title Spore has been rather hotly anticipated for some time now. Publisher EA has set a release date of September 7 for Mac and PC. Additional mini-games based on the full title are planned for the Nintendo DS and mobile platforms.

The game will simulate the creation of a spacefaring race beginning at a pre-bacterial stage. Wired has more information and screenshots with comments by Wright. Interestingly, Maxis will be distributing the creature creation module in advance of the game, with purchasing available through the creator software at launch.

The game's scope and reach are ambitious; combining original gameplay with elements from Sim titles, RTS games, shared user-created content, social networking, and more. It also utilizes procedural programming of such disparate game features as background music and types of populated worlds in the galaxy you'll eventually explore. Lastly, the goal of the developers was to satisfy as many different types of gamers as possible, making the game deep enough to satisfy micromanager types bred on games like Civilization but with ease of play similar to the Sims style games for the more casual players.

Originally titled SimEverything, the title change to Spore is interesting. One the one hand, it seems to give up a the coattail effect of a built-in audience from the namesake series, but may allow exposure to a wider audience by not giving the impression that it's simply one more game in a similar vein.

The social aspect and community content suggest that popularity will increase the appeal of the game in more ways than one, but similar (though less integrated) features in the Sims have gone largely unused by the players. Done right, lack of additional content or interaction with other players shouldn't diminish the game, but if the externally derived additions are popular, it could add a great deal to the playability and longevity of the title. These aspects may also provide oblique competition for more traditional MMORPG games that encourage social interaction, but without a monthly fee.

I've been looking forward to this game since the concept was announced in 2005. I can't wait to try it, and I hope some of my online gaming friends come along for the ride. As with many things, I'm sure the experience will be better if shared. I may even be able to convince my fiancée to play. Now that, for me, would be a new and very appealing gaming experience.
comments

• acclimation

2008/01/23 00:16 | articles
I used to know phone numbers. For most, if not all, of my friends, family, and other important numbers I needed to dial, I could consult only my memory and tap them out on any convenient phone pad. Then I started using a phone in my home that had programmable buttons, to which I could assign a number and label with a name. This was the beginning, and it was replaced first by a cordless phone with an integral directory, and then by a cellular phone with the same, until today, which involves a mobile phone with an entire address book tucked away in its little brain, which synchronizes with my desktop computer.

Now, I hear or read a sequence of digits once, when I program it into my phone or computer. From then on, those numbers are forgotten, otherwise meaningless data hidden behind an icon on the brightly lit pages of my portable electronic rolodex. The result? Not only do I not know the phone numbers of my friends and family, there's little need for me to. I just press a button with their name on it, and they're as good as rung up. If I don't have my phone with me, however, I couldn't call any of them in the most dire of straits.

The same phenomenon has been slowly occurring for me with email addresses. It wasn't so long ago I could tell you most of the email addresses of those people I most often correspond with, down to the last "@" and ".". Just as surely, though, it is becoming increasingly unnecessary for me to type those addresses out for any reason, since my phone and my computer both know them all, and take care to display them to me as an instantly recognizable Firstname Lastname pair. Which is nice, and what one might expect from a modern email client, even if it is on your phone, but brings me to the same condition I'm in with phone numbers; I don't remember email addresses, because I don't have to.

What does this bring me to? Partially, recognition of another effect of technology on my life that I've been becoming increasingly aware of. If we rewind the clock a bit, back to when I was first forgetting people's phone numbers in lieu of my phone remembering them for me, we'll see me getting my first real work out of a personal computer. Up until then, they were largely a source of entertainment, games and even the internet at the time were enjoyable pastimes. Increasingly, however, a computer was becoming more and more a tool for managing certain aspects of my life outside of leisure time. I was about to embark on a new path which would make computers and related technology my career, and perhaps because of this, I have come to depend on computers a great deal, and not to simply keep the heat on, so to speak.

The evolution of a computer's place in my life rapidly moved from wondering what I was going to do with one to wondering how I ever lived without one. Soon, always-on internet access followed the same path. At first I would have had a hard time justifying connecting more often than was necessary to send and receive email, which at one time was perhaps once a day. Now, I send and receive email and instant messages almost constantly, and immediately notice any loss or even slowdown of connectivity. The computer itself graduated from novelty to necessity, and now its connection to the world has become so part and parcel to its functionality that it seems nearly useless without that connection.

Which brings me back to the technology that started it all - the phone. What I carry today in my pocket is more accurately described as a computer that can–almost incidentally–make phone calls. In fact, its principle use in day-to-day tasks for me is more email than voice calls. Like constant internet connectivity and the computer which came before that, I find myself wondering not how I ever lived without it, but how I would live without it now.

I can only assume this trend will continue, and that tomorrow I will become not only familiar–acclimated–to a new technology that today I couldn't think of a practical use for, but that I'll wonder how I'd be able to conduct my life without it. One step further away from knowing someone's phone number, or email address, or...

What's next? Will I forget what people look like, not because I've never met them, but because it will no longer be important because a device will recognize them for me? Will digital signatures or audio watermarks be a more readily accepted verification of a voice message than my ability to identify someone based on the sound of their voice?

Time will tell, the old axiom goes. Rest assured, though, that at least for now, I will remember what you look like. Although, I will probably forget your name if we've only met once or twice. Hopefully soon, I'll find a phone that will be able to remind me, at which time I'll have no need to remember it myself. I suppose I should say "it's been nice knowing you."
comments

• update: putting a leash on the leopard

2007/12/19 06:41 | articles
TimeMachineScheduler, which I mentioned in this article, is an easy way to change the frequency with which Mac OS X 10.5's new feature Time Machine backs up your Mac. There's another way, though, that's a bit more daunting for those not comfortable with command lines, but offers just as much control.

There are a number of other things you can do to change how 10.5 "Leopard" works while you're there, though, and I've compiled some of the ones I've found useful here.

First, how to change the Time Machine backup interval (default is 3600 seconds):

sudo defaults write /System/Library/LaunchDaemons/com.apple.backupd-auto StartInterval -int 7200

Changing to the Tiger-style "flat" dock (rather than Leopard's 3D dock):

defaults write com.apple.dock no-glass -boolean YES

Make all items in the dock spring-loaded:

defaults write com.apple.dock enable-spring-load-actions-on-all-items -boolean YES

Enable iCal's debug menu, like the one in Safari:

defaults write com.apple.iCal IncludeDebugMenu YES

Enable a network browser in Screen Sharing's startup dialog:

defaults write com.apple.ScreenSharing ShowBonjourBrowser_Debug 1

and enable an expanded toolbar for Screen Sharing (the send/capture clipboard is particularly useful):

defaults write com.apple.ScreenSharing 'NSToolbar Configuration ControlToolbar' -dict-add 'TB Item Identifiers' '(Scale,Control,Share,Curtain,Capture,FullScreen,GetClipboard, \
SendClipboard,Quality)'
comments

• feedback: credit where credit is due

2007/12/16 21:21 | articles
I doubt anyone at Microsoft considers Vista a smash hit. I'm sure there were enough specials and rebate deals offered near the end of 2007 which will allow them to report strong sales of the new operating system for the holiday season, and enough of their business customers are probably upgrading that they can point to "strong" adoption in certain spaces, but it remains that the latest update to Windows isn't exactly a barn burner.

In the original article my inference is that Vista is actually bad software in the sense that it's poorly coded, but that wasn't precisely what I meant. Vista could be technically perfect; rock-solid, secure, and feature-rich, but if those features are not what the customers demand, or worse, features they do not want, it's bad software.

Microsoft missed its target market with Vista. Businesses aren't adopting it; many vendors are now offering XP alongside it; Microsoft has already extended the end-of-life of XP and may do so again. Intrusive security features and computationally expensive DRM aren't features anyone wants, even if the intent behind them is justifiable. I think in the end, what Microsoft did was forget who its customers are, or at least badly misunderstand what it is they want.

Apple does this well, by the way, and it's one big reason why they are currently gaining market share. It certainly isn't that Mac OS and the software available for it are perfect. They're just often better, because they include the features their intended customer wants, and--more importantly--don't include features that are primarily there to satisfy Apple or its business partners.

Vista is a turd, and unless the upcoming Service Pack does something to miraculously remedy the issues with its adoption by reducing the headaches its features induce, it will remain one of Microsoft's less splendid efforts.
comments

• credit where credit is due

2007/11/29 12:31 | articles
In this article at slashdot, the submitter says: "I'm sorry to say it, but I have yet to see a rival to Microsoft's scheduling features."

This is probably the best example of what I consider the leading problem in the software community - not just a reluctance to use a particular software package when it ends up being the best solution, but being reluctant to simply recognize it as more capable than the alternatives. It sounds like rage; blindly railing against a software solution because of who produces it.

Microsoft has created a good amount of quality software. The Office suite of applications is probably foremost of them, but they have also hit the mark with their older DOS 6.22, Windows 3.11, and Windows 2000 and XP versions. Yes, they've produced some turds, Vista being a recent example. This really isn't a reason to nail them to the cross, however - at least not all by itself.

There are plenty of reasons to choose to avoid Microsoft and its products without ignoring their features or buying into some kind of zealotry or groupthink. If you have sound reasons for making another choice, then by all means, do so.

But let's not be "sorry to say" that Microsoft has done a good job when they have.
comments

• car magazines

2007/11/24 22:20 | articles
The last couple months, I've picked up the latest editions of Motor Trend, Car and Driver, and Road and Track at the newsstand. Thinking I might actually want to subscribe to one of them again, I figured I'd evaluate the writers and editors, since I've not read any of them regularly in the last dozen years or more.

I used to be a big R&T fan, it being the most racing-oriented of the magazines. MT seemed firmly on the consumer side of things, with CD somewhere in between. How are they now?

For the most part, identical. They cover the same cars in the same issues, and by and large they come to the same conclusions about them. In some cases, they even run the same photos! These three, and magazines in general, seem to have used to have been a useful source of information, and differing opinion. Now I'm not sure I'd know which was which unless I could see the cover.

I wrestle with how surprised to be about this. I don't think I'll subscribe to any of them; if they have an article about a car I really want to read (not likely, given the vapid nature of most of their reviews) I'll likely find it on their website.

And, there's pretty much no racing news at all in R&T any more. They should call it Road & ... Showroom?
comments

• .mac, grapefish, and you (maybe)

2007/11/23 23:35 | articles
The preceding entry might serve as a tiny clue to the fact that grapefish is no longer using the Apple .Mac service to publish our calendars.  (We've told at least one other person this is the case, so it could affect someone.  No, really!)

I switched to a local WebDAV service for calendars this week, because sometime in the past month or so, .Mac's iCal publishing service simply stopped working.  No warning, no obvious errors, nothing.  In fact, the little radio signal icon that appears next to the calendar name in iCal.app vanished, too.

Interesting, to be sure, so close to the release of OS X 10.5, or Leopard, as it is known.  There promise to be nearly magical synchronization features in the new version of Apple's operating system, so I assumed they were overhauling aspects of the .Mac service in anticipation of its arrival.

However, there are people who actually USE the services the current .Mac provides, as unreliable, slow, and expensive as it may be (along with many, we are the Blind Faithful, continuing to subscribe to a service that does little for us, but has so much potential, in the hopes that it will someday improve enough to be worth what we pay for it).  Since it is a paid service, and since we do use it, I was at least a little annoyed that one of the features we make heavy use of just up and quit.

It's damn convenient to publish our calendars in this way - we subscribe to the published version of each other's data, and so whenever Eden makes an update to her calendar, it appears on mine.  The reverse, of course, is also true, and it's just like a bit of magic when I use my iPhone to schedule something and the next day (after I've synced) she knows about it, without us having to actually speak to one another.

So here we are - using a service we pay for and it stops working for us.  When I try to manually refresh the published version of my calendar, I'm told the connection to the server failed.  Well, no surprise there, but why?  The dialog references no error number I could search for on Apple's support site.  The system logs revealed no obvious distress on the part of iCal.app.  It Just Didn't Work.  Eden complained she could no longer see my calendar items, which was the last straw, so to speak, and since I had little to go on and less to access even if I discovered the problem, I opted for a different method.

The .Mac service uses WebDAV for the bulk of its features; the aforementioned calendar publishing is one; iDisk online storage is another, so is the new photo publishing feature they call Web Gallery.  This being the case, it was a relatively simple matter to set up the WebDAV server right here at grapefish.org and use it to publish those calendars instead.

Once I had done that, it was also possible for me to mount my WebDAV folder on grapefish.org on my desktop at home, like any other network drive.  This is something I've been meaning to do for a while, actually, since scp and its brothers are, one could say, clunky when compared to the rest of the Mac UI experience.  Drag and drop file transfer between my desktop and my internet server is a much nicer alternative, and in doing what I had to do for iCal.app, I got it for free, essentially.  Which brings us back to .Mac.

I've now replaced two core .Mac services with identical but better performing substitutes on my own server, where I can see both ends of the connection (and both sets of error logs), so that if something does go wrong I am certain to have all the information I would need to correct the problem.  I'm still paying for .Mac, and will again when it comes time to renew--before the release of Leopard--since I still see a lot of potential in the future.  However, doing so after so long with little to no improvement in either performance or features leaves me feeling a bit like a sap.  I've been here before, though this time does seem a bit different.  Time will tell, I suppose.

Is eight bucks a month enough to really get twisted up about, in the grand scheme of things?  Not really, I suppose, but there is a history I've established that instead of paying any amount, even nothing, in GMail's case, for an internet service that doesn't work flawlessly is vastly inferior to simply owning the service myself.  If it doesn't work flawlessly, I can fix the flaws.  If it doesn't work at all, I can usually determine why, and fix that, too.

And that's worth quite a bit.
comments
next page...