|Home » Products » Reviews » The Very Ugly
Bare Bones Software (Rich Siegel)
Two to three hours. Nearly nine years. 'Progress'.
Progress: a phenomenon as old as the planet itself. The inevitable move forward. Cro-Magnon becomes Homo Sapiens. A mammal walks and talks. Man learns electronics and invents the computer, then the transistor, then the circuit board. VLSI follows and with that the era of the microcomputer.
Operating systems reach a certain sophistication and with them the idea of a graphic user interface. Central processors move from 4-bit to 8-bit to 16-bit to 32-bit to 64-bit and beyond - and as the CPUs grow stronger, we get better and better systems with more and more stability and security.
One Alan Kay comes to the Palo Alto Research Center and works on object orientation, electronic mail, networking, and graphical interfaces with point and click. Years go by and suddenly everyone is trying the same.
Steve Jobs leaves for Redwood City and then comes home to Cupertino with a next generation operating system and development platform. They're called OS X and Cocoa respectively.
Because of massive protests amongst the third party vendors of the day, concessions are made: old APIs are wired mercilessly into the clean body of code of this system - concessions that are expected to phase out with time.
End users are mostly kept in the dark about all this. They see subtle differences between the native applications and the dinosaurs but they're not studying the code and trying to understand the system on that level - they're only trying to use it.
Apple have made it very easy to migrate to the new platform. The task of learning Objective-C, the programming language at the heart of it all, is not a challenge at all. It takes only a few hours - not days weeks or months - to get going. It has been in Apple's interests to see developers take to the new platform and quickly. As Steve Jobs once said, once you lose the third party support you lose it all.
Work on this new operating system began eight - nearly nine - years ago. That's enough time for most people in the IT industry to get a bachelor of science degree, a master of science degree, a PhD, and make enough money to comfortably retire.
It's a long time. For example, the Internet as we know it today has only existed slightly longer.
So expecting third party vendors to make the leap (more like an unnoticeable skip) to this new platform, at least in the nearly nine years that have transpired, isn't out of order. On the contrary.
But today lines are getting greyed out again. What was obviously 'native' only a few years ago has now expanded to include many things that aren't strictly speaking native at all. Dinosaurs such as 'Classic' which are supposed to be phased out are not being phased out at all. And features which do not belong in this new system at all were expected to be gone by now but they're not.
Clearly something is wrong. Clearly the ship has a faulty rudder. Either that or someone is pulling hard on it.
|'Is it really that hard to add IMAP support? The Bare Bones folks don't even seem to be trying with this application.'|
'Yeah, whatever. Still no IMAP.'
'It just works.'
'Yeah, well PINE 'just works' as well - doesn't mean you should use it as your Mac mail client though.'
Running OS X potentially exposes the user to three operating systems all at once. The first of course is OS X itself; the second is the 'hot wiring' of old APIs into the new system - it is called 'Carbon'; the third is even more alien and is really an old version of 'MacOS' - a 16-bit system that has no business running in a new and modern environment. It's called 'Classic'.
Running Classic officially requires starting the so-called Classic environment. This is akin to a virtual black box running inside the operating system OS X. It has one thread of execution for all the programs running in it. It is crash-prone, and if one thread in any program anywhere should misbehave, the entire environment comes crashing down. All the other programs disappear.
And Classic can have no security. It is 16-bit code and cannot provide protected memory, resource access control - none of that. It's code used to dealing with a world where the greatest possible threat was from someone who had a key to a door.
Nor can it have stability - and the entire OS X suffers as a result of its use. For when a thread of execution goes into that 16-bit Classic code, all bets are off. A system of structured exception handling won't save you. And for this reason entry to 16-bit code is usually done on a first come first served basis, with only one thread at a time gaining access. So it's slow as molasses too.
There are no two ways about it: using Classic is not good, and Apple sincerely believed their third party vendors would have got on the bandwagon long ago. For there is no real reason to even ship the Classic environment anymore, much less use it.
Mailsmith has made a curious transition: it's still 16-bit code (and of a monstrous size) but it's being run through Carbon and OS X. There are some funky things going on in there. But one thing Mailsmith is not is true OS X application code.
It's not native. In the nine years Bare Bones have had to 'get with the program' they have done nothing. Instead, as many bitter users express it, the only things changing are the prices - inevitably spiraling upward.
One can ask oneself as well what one needs with yet another mail program. Apple provide Apple Mail, a perfectly adequate program despite complaints about its UI with Tiger, and miles ahead of Microsoft's Outlook. It is secure, it offers a lot of features Microsoft and other vendors do not provide - and it is free.
It's also native OS X code - 'Cocoa'. Its executable is only one sixth the size of Mailsmith and it does just as much in that code. And taken as a package it's a lot more bang for buck than that.
Look - a Wheel!
Mailsmith is effectively telling you 'look - a wheel!'. Countless features are already provided in your operating system and you might not know it.
Mailsmith comes with a dozen or so dictionaries in exotic languages for your spell checking (and goes one further by providing you with a juicy bible dictionary too), but all of this is already resident on your system disk.
In fact, spelling is an integral part of the entire operating system and available in all applications at the click of a mouse. Shipping a new standalone spelling system is simply bad design - extremely poor design.
You can even set Safari to do spell checking for you in web forms you write in. You get OS X spell checking everywhere.
And the OS X spell checking is multilingual too: you can write interchangeably in English, American, French, Portugese, Italian, German, Swedish, Norwegian, Canadian English, Brazilian Portugese, and Dutch - and the spell checking in OS X will take care of them all and all at the same time (and yes in the same document).
Anywhere you want. At any time. In any program.
So why would you want a new program with its own spell system which does not serve your entire operating system and won't integrate with it?
Mailsmith contains thirteen dictionaries: American, Biblical, British, Dutch, French, Legal, 'Legal Secretary', Medical, 'Name', Pharmaceutical', 'Post Office', Science, and Spanish. It is not known if these esoteric 'dictionaries' contain terms not found in standard dictionaries, but it is obvious that a good dozen of the languages supported by OS X are not supported by Mailsmith.
A major blow to global communications...
And as Mailsmith is not a native OS X application, it cannot take advantage of the built-in spelling system either. Those great benefits only accrue to the third party vendors who've taken the time to make their code 'progress' - starting with those two to three hours to learn Objective-C...
The actual packaging of Mailsmith is itself a wonder, with .DS_Store files littered all over the place in areas where they can never be used. Even if one agrees to cut .DS_Store files a little slack, one must admit they're only relevant where folders are to be displayed. And folders inside the Mailsmith package such as 'MacOSClassic' and 'Plugins' and 'Mailsmith Help' and 'Sounds' and 'Resources' and 'Contents' and even 'Mailsmith.app' itself are certainly not folders of that type.
And yet the user is expected to accept an additional 60 KB of the download for this - it's only there because the 'packaging' was done sloppily or by someone not fully aware of what they were doing or both.
And do we really need an additional 7.2 MB in sound files? To signal incoming mail in twenty nine [sic] ways? Especially when the operating system has an adequate number of sound files of its own?
It might be OK to offer these sound files as add-ons to the program or the system - but to package this inside Mailsmith and point to it as a feature?
Are we arguing that 'bloat is good'? Are we counting on users assuming 'the bigger the download the better the code and the better the program'? It's just extravagant in an inexcusable way.
'12-String Strummer', 'Acoustic Piano Diddy', 'Bluto Stomp', 'Boomba Hey!', 'Classic Kiss', 'Crypton Cave', 'Deep Bender', 'Dream Sequence', 'Fairy Wink', 'Fickle Sunshine', 'GhostGiggle', 'Key Hop', 'New Mail (Female, NoFX)', 'New Messages (Female, Prof.)', 'Offertory', 'Peculiar Omen', 'Presenting...', 'Saturnian Broadcast', 'Somewhat Closure', 'StarWish', 'That 60s Thing', 'Trek Whistle', 'Vhat Is Dhat?', 'Warning Tone', 'wHOduniT', 'You Have Mail!', 'Zlip-n-Zlide' - how cute, but is that programming, and is it what you want in a mail program?
Note that even if these sound files will 'work' under OS X, they're not of a native format: they're compatible only with the old Classic Mailsmith runs on. (Yes, even the sound files are outdated.)
OS X users don't need to see the wheel reinvented all the time. Once is enough. They don't need to download a new Trash icon when they already have it on their system and on their desktop. They don't need to download twenty nine sound files when they're expecting an electronic mail program.
And they probably don't need a new electronic mail program either. Certainly not one which lives in the past, depends on outdated technology that has no part in OS X, and which puts the stability and security of the system at risk.
But there's more, for even if you washed away all those doubts, you're still stuck with the performance of Mailsmith as the mail program it's supposed to be. And for you to even consider using it instead of the system default you'll have to find one feature at least which you feel is worth the unbelievable price tag of $99.
So what does Mailsmith have that Apple Mail does not?
It will not display HTML mail period. This is admirable but probably dependent on the fact it simply cannot: once again, HTML rendering is integrated into the operating system OS X as a whole - but because Mailsmith is not a 'native' OS X application, it cannot take advantage of this.
Apple Mail will do more important things than show only raw HTML source anyway. It will refuse to resolve web references, and it will absolutely not run any client side code. So safety is not jeopardised. And if you want to see the actual HTML code you can - and in a way not possible with Mailsmith.
For Apple Mail stores your mail messages in the format they're sent in, but Mailsmith does not. If something would happen to your mail program, you could go into your Mail folders with any text editor and get your messages out. You can't do this with Mailsmith, which like MS Outlook chooses to store your messages in an unfriendly 'binary' format, so if the program crashes your mail might be lost.
Apple Mail conforms to the World Wide Web Consortium recommendations for mail storage; today each message is saved in a text file of its own. Mailsmith fails also here in keeping up with progress - and endangering your information.
Mailsmith cannot handle 'format flowed' messages which are finally coming into their own; Apple Mail always has been capable of this. Offering 'Re-wrap Quoted Text' in this context is hardly a consolation, as the messages created are already such a mess themselves. And it doesn't help you anywhere else - web forms et al - either.
Mailsmith's text rendering system also leaves a lot to be desired. And so forth and so on and so forth and so on. And let's not forget the not so infrequent crashes - something almost never seen with Apple Mail.
6,633,382 bytes. That's the size of the Mailsmith 'MacOSClassic' executable itself - the entire package is a monster. Six megabytes for what Apple Mail and other OS X applications can do in one tenth or less - plus over seven megabytes for sound files you'd be fine without and probably wanted to have only as an opt-in anyway, plus a spelling system you cannot integrate with the system with very few languages actually covered.
Integration with OS X: you miss most of this. OS X is all about not reinventing the wheel. It's about gobs of space age features applications like Mailsmith can't get close to because their authors never took those two to three hours to acquaint themselves with Objective-C and start migrating their code to the new platform.
And that was nearly nine years ago. It's almost as if people are getting tired of waiting.
Whatever: if you've tried Apple Mail and really don't think it will serve your purposes, think long and hard about it: it's provided by the people who gave you your operating system and your computer. They're fairly capable developers. And they write programs that show evidence of the progress that's been made. And they gave you that program for free.
If you still don't want Apple Mail, then do try Mailsmith - so you at least know what you'd be in store for. But keep the above in mind so you don't get more than you counted on.
For you're probably counting on 'progress'.