Opinion

Windows Could Use a Rush of Fresh Air

It's got to be bad when the New York Times starts going public about how bad your OS is:
Beginning as a thin veneer for older software code, it has become an obese monolith built on an ancient frame. Adding features, plugging security holes, fixing bugs, fixing the fixes that never worked properly, all while maintaining compatibility with older software and hardware — is there anything Windows doesn’t try to do? [emphasis added]
This is, I feel, the biggest problem with Windows – it tries to be everything for everyone and hence has very little room to move around, because there are just so many constraints binding it.

Labels:

 

Posted on at  

Birthday Party Snub Sparks Debate

This is so outrageous, it's actually funny.
Discrimination row after child denies classmates party invitess

Labels:

 

Posted on at  

Resuming Time Machine Backups on a New Computer

In all the times I've switched computers or reinstalled Mac OS X since Leopard came out, I've noticed that Time Machine is, in general, not very happy about letting the backup volume make the smooth switch as well. Basically, if you were making regular backups on machine X, then bought machine Y and restored your backup onto Y, when you hook up your backup volume to Y and start doing a backup to the same disk, it's either going to tell you that the backup disk wasn't found or start doing a full backup all over again. Currently the only way to avoid this is to follow the instructions in the linked article, which I followed (but not to the step because a couple of the commands didn't work) to resume using my old backups with my new computer. Although this is probably not a super-common issue, I believe that it's a big hassle for people switching computers and that there should perhaps be something in the Time Machine options that let's you sync with a pre-existing backup volume. (Apparently, Time Machine distinguishes between computers based on the Computer Name and the Primary Ethernet Address.)

Labels:

 

Posted on at  

Google I/O Videos

Worth a watch, especially if you're into Web.

Labels:

 

Posted on at  

Ligatures in Firefox 3

Trying hard to impress but not doing a complete job of it.

Labels:

 

Posted on at  

Firefox 3

Firefox 3 is out. Go download it and help them set their world record. The biggest addition for me is (finally!) the addition of Hindi viewing and composing support. I tested it using the Hindi Wikipedia as well as using Blogger's Indic Script Transliteration tool and it works fabulously. Firefox can still not be my default browser due to its non-native look and feel but it's good enough for most people.

Labels:

 

Posted on at  

Reflections on WWDC08

Now that WWDC08 is over, I thought I'd take a little time to look back at what happened from my point of view in terms of new information, and no, I probably won't go into detail about how, although they had free Odwalla, the food provided there was frankly speaking quite shitty.

Garbage Collection
I can't remember a single session I attended in WWDC08 that didn't have at least a slide or a mention of GC – it was everywhere. This is something Apple seems to be pushing big time in the yet-to-be-released Snow Leopard and wants developers to adopt it. However, GC is not the panacea that it kind-of is in Java.

The first factor to consider is the "opt-in" nature of GC in OS X, which means that any application can choose to run in GC or non-GC mode. And regardless of which mode an application chooses, any frameworks it uses, any plug-ins that hook into it, must also be capable of running in either mode as required. This means that framework/plug-in writers have to deliver a single code base and a single binary that supports both GC and non-GC. The Apple frameworks already do this.

The second factor to consider is that if you as a developer think that for every kind of creating-something-that-needs-to-be-freed-later function call, you can simply omit the corresponding 'free' call, it's far from the truth. GC applications do eliminate a lot of tedious memory management, but they aren't simply programs without the memory management calls – or at least not in Objective-C 2 – and getting an existing application moved over to GC might not be without its bugs (there can, ironically, even be memory leaks with GC on when there weren't any with it off).

Thirdly, even Apple admits that there are certain applications which should not be GC'd because they require the assurance that nothing else is running that could even potentially slow down performance for a millisecond and should thus manage their own memory in their own complicated ways. In fact, Apple itself hasn't yet ported most of its applications to GC. One of the few it has is Xcode 3.

Finally, GC in Objective-C 2.0 is optimized for Objective-C objects and that means that unlike porting pure Objective-C code over to GC, porting C/C++ code base might prove to be either infeasible or even impossible. Even in GC mode, for example, any memory allocated using malloc still needs to be released using free and CFRetain calls need to be matched with CFRelease calls respectively – the application maintains a separate malloc zone and a GC zone on the heap.

However, although this prevents any large developers with giant applications (such as Adobe or Microsoft) from switching to GC for many years to come (hence Apple making this opt-in, I feel), GC is a great boon to both new developers who don't need to worry about memory management from the get-go and to existing developers with comparatively smaller code bases who can transition to GC in their next release cycle. And Apple is providing some magnificent incentives for these developers to do so. For example, GC is going to be six to ten times faster in Snow Leopard, not only compared to Leopard GC but also to traditional malloc. And to developers, this gives them a concrete incentive to transition their code over to GC, in addition to cleaner, more manageable code. And, from my point of view, this is as good as it gets because I get to continue along the path of not including memory management code in my application while having my already-fast application receive a free speed boost come Snow Leopard some time in 2009.

Multithreading
Being able to spawn off multiple threads to do their bidding more efficiently in parallel has been something that programmers have been able to do for many years now. However, in order to achieve this, they have to significantly alter the structure of their existing single-thread code base and endure much toil while doing so. What is Apple doing about this? Apple is not providing a magic pill to solve one of the very basic problems of multithreading, i.e., deadlocks, however, it is making multithreading a lot more easier and accessible in Snow Leopard, in which developers can designate certain bits of code to run inside "blocks". By specifying some code inside a block, the developer tells the OS that that particular piece of code can be run in its own thread if the need arises. Thus, when the application runs, Apple's new "Grand Central Dispatch" runtime decides whether it's economically viable to spawn new threads to run the code (based on system load and on the number of cores on the machine), and if it is, it makes the new threads, but also cutting them back when it needs to. This basically means that developers never have to bother with ever manually spawning threads and can instead just make their code thread-compatible and let the OS take care of squeezing the most performance out of it.

Rosy picture aside, the two major caveats that come with using blocks seem to be that (a) you still take care of deadlocks, etc. in your code and (b) the syntax for creating and using blocks looks ugly as fuck. If you've seen function pointer syntax in C++ and shudder at the thought of ever writing another one, think that except worse.

Deeper into Objective-C
This is just personal experience by my going to WWDC for the first time but it's like I've discovered this whole hierarchy of programming interfaces beyond the "NS" frameworks that were basically all my world until last Sunday. I find that I now understand a lot better how the Mac OS X programming stack works and how many layers there are and where the boundary is between Cocoa Animation, Core Animation and OpenGL, etc. And I feel that even though I won't be using much of the programming API beyond the NS-level classes, it makes me more at peace knowing what's going on underneath. Also, my definition of what's considered "easy-and-straightforward" has been tickled a little because people at WWDC throw more into that category than what I would normally allow. 

Comments (36) Posted on at  

More about Snow Leopard

RoughlyDrafted provides a more detailed explanation of Snow Leopard's features.

Labels:

 

Posted on at  

Snow Leopard

Even though Apple did not show the Snow Leopard presentation to the whole wide world, there is this page containing snippets of information. Snow Leopard looks to be a good move for Mac OS X, especially since it's going to get harder and harder to add features that can count as "major breakthroughs". Snow Leopard does pack a lot of new features but all of them are low-level features which only developers can truly appreciate and so Snow Leopard might be a hard sell for Apple if they intend to charge the same $129 for it.

Labels:

 

Posted on at  

Time Machine over AirPort Extreme

A couple of months ago when Apple finally (and quietly) enabled the feature in Mac OS X that allowed hard drives connected to AirPort Extreme base stations to behave the same way as Time Capsule volumes, i.e., allowed them to be used for Time Machine backups, they insisted that this was an "unsupported feature". Being the owner of such a set up, in my excitement of being able to have wireless backups, I blatantly ignored aforementioned warning and went ahead and set up Time Machine to use that drive for backups.

And everything was blue skies and sunshine until yesterday arrived.

That was when I started getting "Time Machine Backup Failure" messages and after a few of these (including some that ironically told me that my backup disk was failing and I should back it up), I disconnected the backup drive from the AirPort Extreme and plugged it in directly to my Mac. Apparently, the disk image inside the backup volume had become disastrously corrupted, which meant that even multiple sessions of Disk Utility weren't able to repair it, and in the end, deciding that trying to repair the backup disk image was not worth my time, I just erased the disk. I'm going to use it over USB from now on.

Bottom Line: When they say "unsupported", they mean "unsupported", so don't use Time Machine with disks connected to AirPort Extreme base stations. However, I do have to say that if it's "unsupported", why is it exposed in the UI in the first place? 

Comments (0) Posted on at  

Ludicrous Rumors

Apparently it's the time of the year again to make ridiculous rumors. First of all, I feel it's a bit excessive to expect Apple to ship a major update to Mac OS X barely a year after the previous one because, as Mac OS X matures, these major updates are only going to be harder for Apple to ship, not easier. If anything does ship in that time and it's not a free update, I don't think it can possibly have more features than a 0.5 update, i.e., no major OS changes. And these are already delivered incrementally through the 0.1 updates. In addition, the comment about 10.6 switching to "pure Cocoa" seems incredibly ludicrous considering the Finder is an extremely important and extremely massive application that's still in Carbon and it's not going to get converted to Cocoa by January 2009. Ditto for Final Cut Studio applications, most of which, such as Final Cut Pro, are in Carbon right now. Of course, considering the fact that Carbon is doing no harm just sitting there, why Apple would want to get rid of it in the first place is beyond me.

Labels:

 

Posted on at  

News